 | |
Converting large single-file solution into separate data and interface files
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Converting large single-file solution into separate data and interface files -
04-30-2007
, 04:58 PM
#2
| |||
| |||
|
Hi all  Some time ago, I wrote a rather large database (over 20 tables, with each table having 2-10 occurrences in the relationships graph), all in a single file. I've now realised I need to separate the data from the interface, to simplify ongoing development. My question is: is there a simple(r) way to do this - I've made a clone, and am currently working in the relationship graph, calling up each table occurrence and redefining it to link to the new data file - this takes a lot of time - can I script it, or is there a utility to move them all at once, or any other faster solution? thanks very much!!! julie |
it makes it more complicated.
You do get the bonus that you can create simple report layouts and user
/ data entry layouts in the "interface" file without too much trouble,
but in my experience you often have to add more data fields, etc.
anyway which means you have to update the "data" file.
It really depends on what your future "updating" of the database will
require.
Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
#3
| |||
| |||
|
|
In article <1177970339.222205.96... (AT) n59g2000hsh (DOT) googlegroups.com>, whitehawk <whiteh... (AT) pacific (DOT) net.au> wrote: Hi all Some time ago, I wrote a rather large database (over 20 tables, with each table having 2-10 occurrences in the relationships graph), all in a single file. I've now realised I need to separate the data from the interface, to simplify ongoing development. My question is: is there a simple(r) way to do this - I've made a clone, and am currently working in the relationship graph, calling up each table occurrence and redefining it to link to the new data file - this takes a lot of time - can I script it, or is there a utility to move them all at once, or any other faster solution? thanks very much!!! julie Separation doesn't actually simplify development - in fact in some ways it makes it more complicated. You do get the bonus that you can create simple report layouts and user / data entry layouts in the "interface" file without too much trouble, but in my experience you often have to add more data fields, etc. anyway which means you have to update the "data" file. It really depends on what your future "updating" of the database will require. |
hours during deployment / cut-over of updates.
In theory, if you make offline updates to an interface file you can
just cut-over by dropping the new file in, potentially saving hours or
even days of importing records.
In practice it almost never works out that way, some tables invariably
need additional fields, or autoenter criteria, or lookups, or whatever
to support the new UI file. But usually its only a small percentage of
the tables.
In a 20 table solution, if you need update it, and change the
interface layer, and as a result modify 2 to 3 of the 20 tables, you
still eliminate having to import 17-18 tables. That can add up to
serious time savings.
-cheers,
Dave
#4
| |||
| |||
|
|
On Apr 30, 5:22 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com wrote: In article <1177970339.222205.96... (AT) n59g2000hsh (DOT) googlegroups.com>, whitehawk <whiteh... (AT) pacific (DOT) net.au> wrote: Hi all Some time ago, I wrote a rather large database (over 20 tables, with each table having 2-10 occurrences in the relationships graph), all in a single file. I've now realised I need to separate the data from the interface, to simplify ongoing development. My question is: is there a simple(r) way to do this - I've made a clone, and am currently working in the relationship graph, calling up each table occurrence and redefining it to link to the new data file - this takes a lot of time - can I script it, or is there a utility to move them all at once, or any other faster solution? thanks very much!!! julie Separation doesn't actually simplify development - in fact in some ways it makes it more complicated. You do get the bonus that you can create simple report layouts and user / data entry layouts in the "interface" file without too much trouble, but in my experience you often have to add more data fields, etc. anyway which means you have to update the "data" file. It really depends on what your future "updating" of the database will require. In a large solution, separating code from data can save countless hours during deployment / cut-over of updates. In theory, if you make offline updates to an interface file you can just cut-over by dropping the new file in, potentially saving hours or even days of importing records. In practice it almost never works out that way, some tables invariably need additional fields, or autoenter criteria, or lookups, or whatever to support the new UI file. But usually its only a small percentage of the tables. In a 20 table solution, if you need update it, and change the interface layer, and as a result modify 2 to 3 of the 20 tables, you still eliminate having to import 17-18 tables. That can add up to serious time savings. |
proves the common sense approach of older versions of FileMaker where
each table was in a separate file.
)In reality, you're probably best to not use a "single file" approach or
have EVERY table in a separate file, but use something in between where
similar tables are in the same file, but very different tables are in
separate files.
Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
#5
| |||
| |||
|
|
In article <1178007777.035110.299... (AT) p77g2000hsh (DOT) googlegroups.com>, d-42 <db.pors... (AT) gmail (DOT) com> wrote: On Apr 30, 5:22 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com wrote: In article <1177970339.222205.96... (AT) n59g2000hsh (DOT) googlegroups.com>, whitehawk <whiteh... (AT) pacific (DOT) net.au> wrote: Hi all Some time ago, I wrote a rather large database (over 20 tables, with each table having 2-10 occurrences in the relationships graph), all in a single file. I've now realised I need to separate the data from the interface, to simplify ongoing development. My question is: is there a simple(r) way to do this - I've made a clone, and am currently working in the relationship graph, calling up each table occurrence and redefining it to link to the new data file - this takes a lot of time - can I script it, or is there a utility to move them all at once, or any other faster solution? thanks very much!!! julie Separation doesn't actually simplify development - in fact in some ways it makes it more complicated. You do get the bonus that you can create simple report layouts and user / data entry layouts in the "interface" file without too much trouble, but in my experience you often have to add more data fields, etc. anyway which means you have to update the "data" file. It really depends on what your future "updating" of the database will require. In a large solution, separating code from data can save countless hours during deployment / cut-over of updates. In theory, if you make offline updates to an interface file you can just cut-over by dropping the new file in, potentially saving hours or even days of importing records. In practice it almost never works out that way, some tables invariably need additional fields, or autoenter criteria, or lookups, or whatever to support the new UI file. But usually its only a small percentage of the tables. In a 20 table solution, if you need update it, and change the interface layer, and as a result modify 2 to 3 of the 20 tables, you still eliminate having to import 17-18 tables. That can add up to serious time savings. That's not really a reason to use "data separation" as such, |
separation.
A lot of the stuff we use fields for in filemaker are done on the fly
in other systems. Like unstored calcs for example, summary fields,
globals, etc. None of that needs to be defined in the 'data'.
Quote:
|
but simply proves the common sense approach of older versions of FileMaker where each table was in a separate file. ) |
separate file was an ok model, but forcing the UI for each table to be
in the same file as the table was beyond annoying.
Not to mention the file open limit.
Quote:
|
In reality, you're probably best to not use a "single file" approach or have EVERY table in a separate file, but use something in between where similar tables are in the same file, but very different tables are in separate files. |
in separate files, and to bundle all the utility tables for the UI in
the UI file.
-cheers,
Dave
#6
| |||
| |||
|
|
On May 1, 2:07 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com wrote: In article <1178007777.035110.299... (AT) p77g2000hsh (DOT) googlegroups.com>, d-42 <db.pors... (AT) gmail (DOT) com> wrote: On Apr 30, 5:22 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com wrote: In article <1177970339.222205.96... (AT) n59g2000hsh (DOT) googlegroups.com>, whitehawk <whiteh... (AT) pacific (DOT) net.au> wrote: Hi all Some time ago, I wrote a rather large database (over 20 tables, with each table having 2-10 occurrences in the relationships graph), all in a single file. I've now realised I need to separate the data from the interface, to simplify ongoing development. My question is: is there a simple(r) way to do this - I've made a clone, and am currently working in the relationship graph, calling up each table occurrence and redefining it to link to the new data file - this takes a lot of time - can I script it, or is there a utility to move them all at once, or any other faster solution? thanks very much!!! julie Separation doesn't actually simplify development - in fact in some ways it makes it more complicated. You do get the bonus that you can create simple report layouts and user / data entry layouts in the "interface" file without too much trouble, but in my experience you often have to add more data fields, etc. anyway which means you have to update the "data" file. It really depends on what your future "updating" of the database will require. In a large solution, separating code from data can save countless hours during deployment / cut-over of updates. In theory, if you make offline updates to an interface file you can just cut-over by dropping the new file in, potentially saving hours or even days of importing records. In practice it almost never works out that way, some tables invariably need additional fields, or autoenter criteria, or lookups, or whatever to support the new UI file. But usually its only a small percentage of the tables. In a 20 table solution, if you need update it, and change the interface layer, and as a result modify 2 to 3 of the 20 tables, you still eliminate having to import 17-18 tables. That can add up to serious time savings. That's not really a reason to use "data separation" as such, That's in large part because Filemaker still doesn't support properly separation. A lot of the stuff we use fields for in filemaker are done on the fly in other systems. Like unstored calcs for example, summary fields, globals, etc. None of that needs to be defined in the 'data'. but simply proves the common sense approach of older versions of FileMaker where each table was in a separate file. )I wouldn't go that far. Perhaps having filemaker tables each need a separate file was an ok model, but forcing the UI for each table to be in the same file as the table was beyond annoying. |
)Quote:
|
Not to mention the file open limit. In reality, you're probably best to not use a "single file" approach or have EVERY table in a separate file, but use something in between where similar tables are in the same file, but very different tables are in separate files. Its also usually beneficial to have large tables with lots of records in separate files, and to bundle all the utility tables for the UI in the UI file. |
file anyway I don't have any choice, and I can't be bothered with data
separation because as I said above (and you said too) the changes
usually mean adding new fields, etc. anyway.
Having said that, in most solutions you often end up with a combination
where some files / tables simply don't need a user interface since they
are controlled via a portal from a parent file / table, making those
files / tables basically "data separated" anyway.
)Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.