Jump to content
Server Maintenance This Week. ×

Trying to split single file solution into multiple files


Jalz

This topic is 6659 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I've almost finished building a new FileMaker 8 system in a single table (but of course with many TO's). I've used the conventional method of building, i.e. put graphics data and scripts all in a single file. My question is, has anyone successfully built a system this way and then split it to Interface and data files. I was at an FSA a meeting and one of the guest speakers said that there was a white paper that illustrated how to do this, but I cant seem to find this on FileMakers website. It might be a resource on one of the Partner level developers site, but I have no idea where to look. Has anyone

I know its not the best scenario, as I should have originally designed it in two files, but I do think that if I can split my data and interface(scripts)- making upgrades to my system would be much easier and less of a problem with data going missing.

I've been reading a couple of other threads in this forum and greatly appreciate some of the findings (pitfalls) others have mentioned.

Thanks

Link to comment
Share on other sites

Your choice of first building your solution all in one file is not a bad idea, since it allows you to get at the different table and relationship definitions quickly. It turns out it's not that difficult to split a single file solution into multiple files. Here's the basic idea:

After making a backup of your original file, make a copy of it for each data file that you need. Let's assume you only need one data file for the rest of this example. So you'll end up with two copies of your file; one that will be the Interface file and the other the Data file. In the Interface file, add a file reference to the new Data file. In the Interface file, delete all of the table definitions, keeping the TOs on the graph. In the Interface file, redefine each of the TOs' source table to use the corresponding table from the Data file. In the Data file, you can then remove most of the layouts and scripts. Some of the relationships in Data file may still be needed for Lookups to work correctly.

Link to comment
Share on other sites

Excellent;

Cheers Ender, your words are exactly what I heard at the FSA presentation. I've managed to locate the developer that has produced this resource, but he hasn't replied to my request yet (but thats because im on the other side of the world and they're not up yet).

I have about 8 TO's with data, is it necessary to split my solution in 8 files? the reason I don't want to is WAN access. Ive checked my solution with 1 file, and its relatively quick; I've also checked a solution I migrated to FM8 from FM6 and the related files took a while to load up (I did have 21 of them) which slowed the whole experience of WAN access for me.

Link to comment
Share on other sites

I have about 8 TO's with data, is it necessary to split my solution in 8 files?

It's not necessary to have separate files for each data table, but it may be desirable for some tables. If a data table holds more than a few hundred thousand records or the records hold container images, then it may be beneficial to have that table in a separate file so that maintenance on that file can be performed separately. Also, if you have a large table that gets cleared out every year, it may be easier to use a separate file for it and simply clone that one file, rather than run a Delete All operation or clone the entire Data file and import all the other tables.

This brings up another point: if you have to do most of the database changes in an offline copy and it's likely that you will be adding fields as you go, then both the Interface and the Data files where the new fields reside will need updating. Using separate Data files for each table makes the import operations easier, as you only need to import the data into the tables that change, rather than all tables in the data file.

It's kind of a balance between ease of design & security vs. ease of maintenance. :)

Link to comment
Share on other sites

  • 2 months later...

Hey, Ender -

You should be a technical writer (maybe you are!)...your procedure for making this work was far simpler and clearer than most of what I've encountered in the online help files.

I followed your steps pretty literally, and everything seems to work fine. Is there any other reduncancy that I can eliminate, like possibly users?

Thanks a bunch...

mz

Link to comment
Share on other sites

This topic is 6659 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.