Delema? 19 Files to be hosted, 26 users?

[BowDown]

I have been developing a new system in FileMaker 8 for the office. I'm pretty much at the point of moving it from a single user system on my desktop, to a multi-user setup on a trial version server.

I have started with my main menu system creating accounts/permission groups and what a pain in the ass this is. I have to do this for each of the 19 files? Is there a way I can kind of blanket permissions on all files, then go back and tweak em? Or do I have to sit here and enter in all this info 19 times?

[Razumovsky]

Hi BowDown,

You might not want to hear this, but yes. Accounts/permissions need to be set in each file. This is another of the reasons why the switch from FM6 to FM7/8 was so helpful; you could collapse many file solutions into multiple tables in a single (or handful) of files. As you are still in the pre-deployment stage, you might want to consider re-structuring your solution into 1 or 2 files (see the Separation Model category on this forum and FM's Migration Foundations and Methodologies for lots of good brainfood about this).

I think you will find that unless you have a very compelling reason for having 19 files, or are not planning on making any more adjustments/updates/expansions to your solution, you will easilty and quickly recoup the time invested in re-design now. There are a lot of additional benefits than just the accounts.

Plus, I understand you can copy and paste tables now in FM8, which should make this process much easier for you.

HTH

-Raz

Edited March 8, 2006 by Guest

[BowDown]

Well the reason behind the 19 files is 6 of them are just converted from FM5. It's an old system that's not worth my time converting over as I will be replacing it soon.

So I took the 35 files we had and combined them down into 13.

I know I could further condense them down, but I tried to keep like data with like data.

1 is main menu driver

1 for dealers

1 for orders

1 for trucks

1 for production equip logs... and so on.

FM8 was awesome though. I love being able to have 5, 6, 7 tables in one file.

[BowDown]

We will use most of our daily things out of 3 or 4 files. I just don't like the thought of putting all my eggs in one basket. Even with nightly backups.

[Ted S]

Bowdown,

If you use Windows integated authentication then you could probably cut down on the number of user accounts that would need to be established. I'm in a similar situation and although it was still a bit tedious to setup initially, it hasn't been bad since then.

[Razumovsky]

I still have some leftover FM6 mentalities as well, but...

If this is a temp situation, before you build your replacement file, I strongly suggest you re-consider the design. FM7 (and 8 hopefully!) is much stabler than earlier versions. I have been using it for a year now on many different files and machines without a single crash/corrupted file. I think your caution about 'eggs in one basket' is an understandable impulse, but the risk can be easily mitigated with good backups (and if you can't trust your backup routine, it doesnt matter how many files you split your data into...).

Plus, things like a main menu file are definitely vestiges of previous versions, IMHO. I strongly suggest the 2 file UI/Data approach (it has made my life so very much easier). I am sure others may disagree, but unless you are developing each of the files as independent re-usable modules, most folks here would also probably say you still have at least 15 too many files. Again, there is plenty of discussion of the pros and cons in the above mentioned places.

As a carrot for you, think about the speed of making changes to the entire way the DB is navigated if there was a single nav script in the single UI file using parameters. In fact, you can have essentially all scripts in the single UI file...

Okay, so I am still in the honeymoon stage with FM7. One year and the spark has not left yet!

-Raz

[Wim Decorte]

FMrobot can duplicate priv sets and accounts across files. You only need it to set it all up once, then run an XML DDR and feed that to FMrobot. Saves you heaps of time.

[BowDown]

Hehe. Well this is my first experiance doing anything with FileMaker.

This project was a huge undertaking... I'm basically taking their system that has been added on for the past 10yrs and rewriting all the logic from the ground up.

The main thing I had to keep in mind is that I need to keep the database layout compatible with the old data as much as possible. Last thing I wanna do is have to key in mindless crap for the next 6 months . This project has been underway for about 4 months now, and I would have to say I love FM8 the more I learn it.

No doubt I will have to change some logic issues, but when I first started the project I didn't really understand how FM8 handled multiple tables in a single file. So I would imagine if you looked at my earlier files and the later files the layout/logic would be night and day.

If I had more time I would prbly go back and clean up the layout a bit, but this project really needs to get put into motion before other stuff gets put on my plate.

Is FM8 more efficient handling large amounts of data in one file? I mean if I had 30 tables, and the file size was like 1GB would it operate better than if I had split it up into 10 files with multiple tables? Not all files are needed all the time. Just a few select get most of the use.

[Razumovsky]

Well, then this is the perfect time to revamp the foundations with an eye towards the future. Shortcuts you take now will effect development over the next decade.

Concerning efficency of handling data in FM8 between one or many files, I dont think there is much of a difference, but will defer to the more hardcore backend folks on the board.

I do believe that instead of that issue, efficency and speed will be primarily determined by your dataflow design and use of calcs/lookups/relationships regardless of a 1 file or 30 file solution.

I suspect that you may have duplicated the layouts in each file. I would at least encourage you to consolidate all your layouts in a single UI file and keep your data in the 14 other files. This would not be that time consuming, and would give you a chance to get familiar with some of the more subtle benefits of FM8. Also, I have noticed that some people now store that UI file on each client machine in a network. I have not expeimented with that method, but if speed is an issue, I bet it would help.

I know, it seems like a headache now, but if you will be working with this DB for a while, you will not be sorry.

*steps down from soapbox*

-Raz

[BowDown]

I will entertain the idea a bit.

When you say UI file you mean you have all your layouts in one file, and they all have fields that are pulled from the data file? Not a concept I even considered, but I can see where that would be a good idea.

Currently I have a file per catagory, then each file contains a set of UI layouts that interface with its data, and related tables.

My mainmenu system has catagories which basically are 1 file per catagory, and the sub catagories are the layouts in the file.

So ya, it's still a modified throwback to the FM5 design in hindsight.

[Razumovsky]

When you say UI file you mean you have all your layouts in one file, and they all have fields that are pulled from the data file?

Exactly. The UI will have no tables or fields (and all your datafiles will not even have to be open), but almost all your relationships and scripts. Take a day and read through the migration paper I linked to on my first post. It explains many of these concepts in thorough detail and is INVALUABLE in taking advantage of the significant increase in functionality that came with the switch to FM7.

-Raz