I assume we don't keep scripts and layouts with the data file component of a data separation model..? I'd better get this right !
If you are nervous, make a back up copy first--always a good idea when you are about to redesign a file.
And I'd keep one layout for each table in that file--set them up for table view showing all fields from the given table. These may come in useful for reviewing the data in large batches during debugging sessions--though you can do the same from the interface file--it just sometimes can be handy not to need switching files.
For the most part, you are correct. There can be a few 'special case' exceptions to that rule.
For example, a script set to "run with full access" only gets Full access privileges for the current file--the interface file and this can require that a script be put in the data file that does the "full access" tasks that couldn't be done from the interface file. (There can be other work arounds, but this is one example of why you might find a script in a data file.)
And an import records script in the data file is almost a required feature so that you can pull data into a new copy of the data file from the previous version should you need to deploy a new version of that file.
Thanks Phil..Just what I need...
...So I can just go in and delete all the scripts and layouts....(except for as you mentioned)? I'm sort of nervous about that for some reason unknown!
Very good..Thanks so much!
With data separation you can also redesign your relationships graph. The only relationships needed in the data file are those required for calculation fields and auto-enter settings (Look ups, calculations) to work. This results in a much simpler relationship graph than needed for the interface file.
All good advice. normancole, keep in mind a few things I learned along the way:
value lists should be part of your DATA file(s) as well, but you can point to them in your Interface file(s). value lists based on fields won't matter. but if you have custom value lists and they need to be updated (if you allow changes by client for example), then they need to reside in a file that also has data and less likely needing update with UI changes
if you have layouts in your DATA file(s) limit access to developer and highest admin. no need to put Summary fields on these layouts, as they are interface elements. most calculations can be eliminated from DATA layouts unless needed, but used sparingly. these layouts may be used for CWP, if at any time you use that method of sharing, or you can create minimal-field layouts for CWP.
if you use WD (web direct) web publishing that can be your Interface layout(s) and/or have separate layouts and/or interface file(s) for WD - it depends on what you need to do.
ExecuteSQL() only needs table occurrences in the relationship graph to work. these can be in any file where the query is executed
for imports/export that occur frequently, I prefer to have those scripts in the DATA file(s) and PSoS (Perform Script on Server) or use server schedules to call the scripts
custom functions may need to be carefully placed
make sure that accounts and Priv. sets are the same in all files, although you can add more limitations on DATA (such as layouts access)
Retrieving data ...