Oppinions Please....

[macmangler]

I am debating with my IT department on final Database Setups...

we disagree on setting up multiple table in one file or making multiple databases. The databases are to organize a print company with everything from Job Tickets, Invoicing, Quotes, Contact, Purchase Orders, Etc.

I am opting for multiple tables... primarily beacause of ease of programming.

I just wanted to collect as much oppinion on the matter to help make a final decision.

Many Thanks!

Mike

[Fitch]

If your files are going to be large, you might want to keep the data in separate files. But do your interface all in one file.

[macmangler]

Not sure what you mean by "large." Right now, a FM6 databse from 1999... is about 20 Megs, has about 20,000 records. Maybe 3 databses would fall under this category, however, they will be better maintained... exporting old data, etc.

[Søren Dyhr]

When Fitch says:

But do your interface all in one file.

Is he absolutely right!!! But then ...are you way into a conversion, thats considerably more work than just dropping the old icons on top of the app's dito.

Next thing is probably a lot of the tunneling done via calc'fields and unfortunatly Lookups - some can't be avoided, but removing some will hone some of the 20 MB off. Only historic data needs lookups! But say you have a lookup image you have populated to all your invoice printouts, if it was done in separate layouts using vertorized graphics instead applied straight to the layout instead of having it all in fields.

I would shy away from the ROI centric migration as soon as posible, the established strategy is drop migrate, and then lump by lump, bit by bit gradually exploit the ability to turn everything into one single file, using all the bells and whistels of say theta joins, script parameters and $variables ...and a lot of multilinekeys and globals dissapears in thin air.

--sd

[John Mark Osborne]

I mostly agree with SD. Yes, convert the solution and spend a little time fixing the things that broke but keep it essentially a FileMaker 6 solution running in FileMaker 8. This will allow you to take advantage of FileMaker 8 Server features and robustness. Where I differ is how to rewrite your solution. I would recommend essentially starting from scratch. Using FileMaker 8 Advanced, you can copy over fields and other schema as you see fit to the new architecture but starting from scratch allows you to review everything from scripts to calculation to relationships without missing anything. Otherwise, your solution becomes a "frankenstein" of old and new. Besides, you will also be able to revisit scripts that don't change from 6 to 8 but might change because you know more.

Also, I would recommend one or two files in your rewrite. The easiest is one file and allows you to centralize security, scripting and everything else. It's the easiest to conceptualize. However, a lot of developers like to separate the interface (layouts, scripts, etc.) from the data. While complete separation is not possible, it does allow you the ability to, let's say, add a layout or script to your interface file without modifying the data file, saving yourself the data import. However, some relational aspects may need to exist in both files and you still may need to add calculations to your data file which will require a rewrite.

It's a long read, but I would recommend reading the migration white papers.

http://www.filemaker.com/downloads/pdf/techbrief_fm8_migration.pdf

http://www.filemaker.com/downloads/pdf/techbrief_fm8_migrtn_found.pdf

Edited July 6, 2006 by Guest

[macmangler]

I definately plan on re writing everything from scratch. It is a great way for a "spring cleaning," removing unnecessary fields and making better calculations because I know more now than I did when I wrote the FM6 files.

If I understand what you mean correctly, I think you mean to keep all my databases separate with little to no layout concept, but have my master file, with multiple tables, that do more looking up and NOT storing data. Essentially lots of portals, look ups and calculations.

I have become fairly proficient at Filemaker... however, I am no PRO.... some of your terminology was a little OUT THERE for me.

To be honest... the one thing that freaks me out the most in all the necessary programming is the "set field" command. I know that sounds nuts.. but, unless I know it well... "setting fields" between files is intense scripting and lots of back door "scratch" or "temp" fields.

I do appreciate your advice on the matter.... all of you have been great assisting me along the way.... thats it... I am buying the FM shirt now!

)

[macmangler]

UPDATE.... set field is easier than I thought.

Overall though.... still alot of additional programming needed here. I will start with an outlined schematic and just follow it...

I agree with guys... also, if I am not mistaken, I think security will be easier with separate files.

Thanks!

UPDATE 2..... wow.... just figured out about Global Storage! )

Ok... this is not so bad afterall!

Edited July 7, 2006 by Guest

[John Mark Osborne]

Security is easier with a single file. Sure, you can now script the addition of accounts but you still need to setup privilege sets and extended privileges in each of your files.

I would recommend also getting the Professional Foundation Training book from the filemaker.com web site or taking the course based on the book which will really teach you how FileMaker 7 and 8 work.

Book:

http://www.filemaker.com/developers/professionaltraining/bookcd.html

Class:

http://www.filemaker.com/developers/professionaltraining/index.html