Jump to content
Sign in to follow this  

Single File Solution

Recommended Posts

overrider    0

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.



Share this post

Link to post
Share on other sites

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

Share this post

Link to post
Share on other sites
overrider    0

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...



Share this post

Link to post
Share on other sites
MoonShadow    0

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. laugh.gif

Share this post

Link to post
Share on other sites
Ender    0

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.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites
MoonShadow    0

Great tid bit, Mike, thank you very much. smile.gif

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.

Share this post

Link to post
Share on other sites
transpower    0

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).

Share this post

Link to post
Share on other sites

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?

Share this post

Link to post
Share on other sites
aislinn    0

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.)?

Share this post

Link to post
Share on other sites

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

Sign in to follow this  

  • Similar Content

    • By Tony Morosco
      I'm a botanist, and the tables I am working with are for tracking botanical garden collections. The data represents plants in the garden, and the plants are tagged and show up in the database.  The tables I am working with were created in FMP 7, and I'd like to open them up in FMP 11 (or later.)  The system hasn't been used in years, but still has valuable information.
      One of the tables is giving me problems using the FMP convert and recover commands.
      These tables are all inter-related.  The main table is the Accessions table, which contains records for all of one kind of plant, from the same source, received on the same date.  It is basically a museum standard.
      The other tables are related to each other through this one main table.  The Species table is related to the locations table through the Accessions table. 
      (i.e.  table A relates to table C through the table B, the intermediary)  
      From the Locations table, we can't see the the species information unless the accessions table is present.
      When issuing the open command on the main table to convert the database to FMP 11, I get the message:
      "Accessions.fmp7" is damaged and cannot be opened.  Use the Recover command to recover this file. When using the Recover command from v. 11, I get another message:
      WARNING: problems were detected while recovering the database.  Please review the Recover.log file to see where problems were found and their severity.  The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file. Recovery results:   File blocks: scanned and rebuilt 563 blocks, dropped 214 invalid data blocks.   Schema: scanned fields and tables, 1 items modified   Structure: scanned; 1 items modified   Field indexes: rebuilt  
      Opening the recovered database, there are only three records present.  There should be hundreds.  So obviously I am looking on how to wrangle this database open.
      I've attached the log file here, as well as the database structure map.  
      The other files have converted just fine.  But since the main table won't open, we are kind of stuck.
      I can share the files with you through Dropbox or whatever, if needed.
      Please let me know any thoughts you have, either basic or advanced.  And ask for any clarifications or additional questions.   :-)  

    • By Tumma K
      Hello, All!

      I am an aspiring developer for Filemaker. The company I work with is stuck in the past working off of Filemaker Pro 4.1

      I was given the task of bringing us up to Filemaker Pro/Server 13. So far my conversion prototypes are successful but we recently had a layout issue that can only be fixed in versions 3-6 (as the file is an .fp3) I work off of a macbook while our network is all Windows 7. In order for me to repair the layouts without tampering our active database, I decided the best option is to repair a copy of our solutions off the network. Unfortunately, when I go to download the trial version of Filemaker Pro 6 off of the respected website, the file is corrupt! I've tried multiple times, with different extraction apps and in different directories.

      My question is;

      Does anyone know a place where I could obtain version 6 (or better yet, 4.0) for an OSX computer? I've looked everywhere!
      Thank you for your time,
      Tumma K.
    • By MrEddByrnes
      I'm hoping my question can have a happy ending. In the mid-90's, I purchased Filemaker 3. When Filemaker 5.5 Pro was released, I bought the update CD, which requires the user to either have FM 3 installed or to have the installation CD for FM 3. I've used it all these years, most recently with Windows XP Pro, and it has worked just fine. The databases I began with were long ago converted to FM Pro 5.5 databases.
      I'm still using FM Pro 5.5 on a laptop with WinXP Pro, but in 2013, I purchased a PC with Windows 8. I haven't been able to install FM 3 on it, therefore can't install FM Pro 5.5. I am retired and rarely use Filemaker, but I have a few Filemaker databases I'd like to add to my Win 8 machine. I don't feel it's worth upgrading FM for the sake of using a couple of databases.
      Has anyone else run into this situation and/or have a (possible) solution? Is there perhaps any other software that can read FM 5.5 databases? Thanks in advance for your help.
    • By bmill
      I am using a custom filemaker solution for medical office billing written with fp5 running on a mac with snow leopard. In addition, I have a patient management db (which I wrote) that is linked through pt. ID number to the billing program allowing transfer of some demographic information (name, DOB, etc).
      Other than being limited by hardware restrictions, the billing program serves our needs for now and upgrading to fp12 will take some time (and money).  In the meantime, I am upgrading my pt. management program to fp13 and would like to move new patient demographic information from the billing program ( fp5 running on snow leopard through Parallels) and the new pt management program ( fp13 running on OS X 10.9) on the same mac.   
      Ideally, demographic information would be entered once into fp5 and then a scipt would make the data available for fp13.
      Any ideas on how to make this work?
    • By randyinla
      Hi, can anyone tell me why my on-line database might have stopped allowing me to delete records?  All of my access privileges and passwords are correct.

Important Information

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