Single File Solution

[overrider]

Hello all,

i made a Solution for my Employer containing about 50 Files in FM6. Everything from Employees, Salarys, Items, Bom, Multi Currency, Warehousing, Drawings Database etc. Now i want to do the whole thing over in Filemaker 7. Now my Question is, how to organize my Files?

Is this the better way?;

The File Contacts will contain Employees, Vendors, Customers

The File Item will contain Item and Bill of Material etc.

Or can i basically put the whole Solution into one File and seperate by tables? How does Filemaker Server treat the Tables within one File? Should i understand the File as a Package, containing many Tables (former Files)?

In my Bom File i will have around 60000 Records a Year, Items will contain 25000 Records a Year. The only thing i need to keep out (i guess) is Drawings, because they would take up a huge amount of Space. I would love to put the whole Solution in one File, but how will that affect the DB Performance? I have around 50 Users in there at all times.

Would you recommend for or against the single file approach? In Case you recommend for the single file, do you think it is a good idea to keep data and interface seperate for performance and robustnes reasons?

I mean, basically i would end up with one file that contains at least 200 Layouts, 200 Relationships or more, 50 Tables, some with over 65000 Records. That is nowhere near filemaker 7 advertised capacity, but what do you guys think? i dont want to develop the whole solution into one file, just to see that it is slow as a snail when my 50 users access it at the same time...

I did read some other Posts on this Forum, regarding the Topic, but noone seemed to have experience yet. Maybe now more people tried different things? I think it is a very important choice to make, one file vs. more files.

regards,

Overrider

[Computer Geek]

overrider, I converted a large 30 file solution. I did one file for tables and one for layouts, relationships and scripts. It works very effectively. I don't have the number of records that you do, but I have the users. I am very impressed with the way that this has changed the way I program.

FileMaker has whitepapers on the subject and you should read them before making a decision. It is a lot of work to get it to two files.

Here is a post that I explained more in before:

web page

[overrider]

thank you for your fast reply. i`ve read the post you mentioned before, my problem is that nobody seems to say yes put it all i none file, or no, dont.

i guess it is largely a matter of experience. however, not even filemaker gives an advice like this, they all say filemaker can hold up to a million tables, but what does that mean? should i develop a one file solution?

if filemaker has whitepapers on exactly that subject, could somebody post them here? my connection to the fm site is having problems since a few days, slow as hell and timeouts all the time. i connect from china...

regards,

Overrider

[overrider]

too bad nobody seems to know an answer. not even filemaker...

[MoonShadow]

Overrider, not everyone agrees on whether a Chevy or Ford is better ... that's why both exist. If FileMaker insisted everything be in one file, some people would be unhappy and the reverse is also true. There is no best way, except what's best for you.

There are pros and cons to both methods. I believe for the more inexperienced, one file would be easier. Separation allows easier modification on the interface while the data is being served. One file is easier for access privileges ... and the list goes on.

Put in your homework but you'll eventually have to step the creek. Splitting one-file into separation is difficult; and combining a separate interface with the data would also take some work so the decision is important - but not critical. With FileMaker, both methods will work well and both will have their unique struggles. But regardless which you choose, you will always wonder if the other option would have been better.

[Ender]

Ho MoonShadow!

One good thing I got out of the Separation Model session at DevCon was a demo of how Wendy and Colleen actually create a separate data file. It was suprisingly easy to split a single file into two.

Here's the method (try it!):

1. Take an FM7 file with multiple tables and make a copy of it for this experiment.

2. Save a clone of the file, which will become the Interface file.

3. In the Data file, delete any relationships that have to do with interface.

4. In the Interface file, delete all data tables, keeping table occurances.

5. In the Interface file, add a file reference to the Data file.

6. In the Interface file, reset each missing Table Occurance on the graph to point to the corresponding table in the Data file.

That's it.

This same method could be used to break up one file into several files. The only hitch is if you want to have each file with it's own interface.

[Computer Geek]

Overrider, I can't say it much better then Moonshadow. Before I made my decision what to do with my large solution, I read everything there was to know from FileMaker. Eventually, I had to make the decision that was best for me. Without actually seeing your solution and know what your skill set is, none of us can tell you which way to go. It is your decision.

[MoonShadow]

Great tid bit, Mike, thank you very much.

I've been reviewing ways of splitting and joining for a few weeks - because one never knows if risking a creek-jump may be needed or wanted and thus, methods of adjustment (both ways) will always be important in my bag of tricks.

[transpower]

An advantage of using a single file is that in Define Database one can more easily jump from table to table to change fields. Of course, in a big accounting system you might still want to use a separte file for each module (like one for payroll, one for GL, one for AR, one for AP, etc.). The file for each module would contain all the relevant tables (like customers, invoices, invoice items for AR).

[Leather Knight]

Hi Ender, Nice post, it has helped me in making my conversion. However, there is one problem I find in this solution. I can't seem to figure it out.

Now that we have a data file and an interface file, we can update the interface file and not lose the data already entered, right??

However, if we add a field in the interface file IE: in a sales db all files are present and work fine. Then you decide to add a second or third address field to the interface. Where does the data get stored? In the interface? Then if you update again, you lose that data from the new fields..

How do we compensate for this?

[aislinn]

Hi Ender!

I've come across this older post of yours regarding the Separation Model. I have no experience whatsoever with this way of working and was looking for some basic info.

Can you recommend some sources with comprehensive information on developing this type of solution (a how-to with info about common pitfalls etc.)?