In it's simplest form the relationships in the data file are required for Calculations and Lookups. This is because the field resides in the respective table in the data file in order to create a subtotal or a lookup that has to be defined in the data file. Some developers also setup cascade deletes in the data file as well.
1 of 1 people found this helpful
Be careful with the cascading deletes. If they exist in any of the files, FileMaker will enforce them. (Found that out the hard way. Had them in both interface and data files; turned them off only in the data file, thinking that would stop it. Didn't.)
Thanks, John ... does that mean, though, that if there are NO relationships in the data.fp12 but the relationships DO exist in the ui.fp12 then the Calculationships and Lookups will actually still work ?
1 of 1 people found this helpful
No the only relationships "needed" in the data file are for calculations and lookups.
to clarify the basic design...
Data file - all tables for the solution. Customers, contacts, invoice, invoice line items etc...
UI - no tables are required but I usually have one table with global fields for doing reports
Lets say you want to lookup the customer name and address to an invoice. You define a field in the invoice table for each value. you setup a relationship between invoice and customer base on the customer ID. so that relationship needs to be in the data file.
Well, yes...and No...because to date I've always designed the data basic structure within data.fp12, like the simple one-to-many relationships but when I need any alias tables I always put them in the ui.fp12 ... am I headed for trouble ? Globals I always store in the ui.fp12 as they're likely to change with new versions, and (hopefully...yeah, right) the data structure is pretty stable except for additional relationships that I put in the ui.fp12...seems to work fine...
I've always designed the data basic structure within data.fp12, like the simple one-to-many relationships but when I need any alias tables I always put them in the ui.fp12 ... am I headed for trouble ?
That sounds like you have the right idea.
Your data file only needs the relationships that are necessary for data. This is driven by the definition of your fields. Does a field need to be linked to another table? If so, provide a relationship, otherwise do not bother.
Your UI file will typically have a much more complex graph because you want the UI to provide all sorts of interesting feedback. The SQL commands reduce the need for UI relationships, so the UI graph can become much simpler too.
Assuming that there are only two files in the solution
- solution_data with the tables
- solution_ui with the userinterface, session tables etc.
The answer is either Yes or No to your question.
The answer is yes there should be no TG's in the datafile
If you choose to use the model all the way through, and are not using calculation fields etc. etc. then you will probably only have those TO's in the data file that are needed for creating accounts etc. etc.
The answer is no, we will have TG's in the datafile
I am strongly proposing separation and keeping all functionality in the UI file and only basic functionality in the datafile. But FileMaker is FileMaker and I suggest that you do not stop using calculation fields. And using calculation fields will imply having at least some basic TG's supporting the calculations in the data file.
If you are going for separation for principal reasons, then you will go for "Yes" to your question. But if you want the best of two worlds you will probably have some TG's in the data file.
We would never have any scripts in the data file EXCEPT for those few used for creating accounts across the soultion etc. etc.
Great points, Carsten, many thanks...I understand