Clone feature?

[metroart]

I'm using Filemaker 6 to develop an automated registration system for a non-profit org. They need to register people 6 months in advance for 30 different programs simultaneously, so they need 30 different sets of forms, each with about 20 automated scripts linked to various buttons on the forms. Developing a master template has not been a problem. But cloning the template is another matter.

To make a copy of the master template, complete with a new set of fields/layouts/scripts is a real pain

[Reed]

Why do you need separate fields for each form. Is none of the information common between the forms? If they are truly independent databases, you can just use the save copy... command to save a clone of the database (all layouts, fields scripts, etc. no records)

Dana

[metroart]

Why separate fields? Each program people register for needs separate fields for things like price, member discount, whether they're staffing, if they're paying with cash/credit/check or using work/study credits, whether they're attending Sat. or Sun. or both days, etc. During the year, a person in the database might take 1, 2 or more of these programs. All this info needs to be tracked in a single database.

[Reed]

It seems like you could divide some of your fields up into separate related tables. It doesn't make sense that you need to make duplicate fields for each of 30 different programs. Maybe you could attach an example file so I could see exactly how you're tracking info.

Are you tracking everything in a single *.fp5 file? If so, what does each record represent? Is it a person, or a program etc.? By dividing things up so you have a People.fp5 file, a Programs.fp5 file, a join file called Registration.fp5, you could do things more efficitently.

Dana

[Ender]

I agree with Reed. Figuring out the best structure can save a lot of data entry time--for you and your users. Below are two ER diagrams showing possible structures. The difference is whether or not a Section entity is necessary.

FileMaker Version: Dev 6

Platform: Mac OS X Panther

[metroart]

Yes, that makes sense. I guess I've exhausted the limits of working with a flat database and have to move up to relational Filemaker 7 (to keep it all in 1 file, instead of 6's multiple files). Thanks for the advice.

[Ender]

What's wrong with multiple files? I've got about 85 in my system ( Job security!)

[metroart]

What's wrong with multiple files? For one thing, it's a lot easier to lose or misplace 1 file from a set of many - or get them confused with similar files in other sets or backups. The people who are using this database are volunteers in a non-profit org. They're not like paid employees -- the're poorly trained and often careless. The database (and especially how to restore backups) needs to be kept as simple as possible.

An even more important reason for not using multiple files with FP6 is that it will only make it harder to migrate to 7. From what I've seen about the conversion process, if you use multiple files in FP6, you can forget about trying to port everything over to 7 -- it'll be easier to just start over from scratch and import all the data at a later point.

[QuinTech]

Art, it seems like it's going to be more trouble for you to try to maintain this all in one file than to do the eventual migration to 7. (BTW, your org. doesn't HAVE to migrate to 7 if you don't want to. Some people still use FM3 because it meets their needs!)

As for users accessing the wrong files, hide all the files deep in the bowels of the system and just give them a desktop shortcut to the one file you want them to start from, then script everything else. If they break it after that, smack their knuckles with a ruler.

J

FileMaker Version: 6

Platform: Windows 95/98

[metroart]

>>Art, it seems like it's going to be more trouble for you to try to maintain this all in one file than to do the eventual migration to 7.

J: I can't maintain this all in *one* fp5 file. I *could* maintain it all in 3 related fp5 files. But if I want to migrate to fp7 (and I do), then it's evidently easier to start over from scratch in fp7 (whether one wants one big file or many smaller ones) than try to convert multiple related fp5 files to multiple fp7 files. THAT is what is more trouble -- at least from what I can tell from the conversion pdf on Filemaker's website -- and from the review of fp7 in the latest issue of PC Magazine.

[QuinTech]

Oh, i completely agree. I haven't done a migration to version 7 yet, but i've seen models for it, and it looks like a b**ch. But you were right when you stated earlier that you have "exhausted the limits of working with a flat database".

Could you get your org. to move up to 7 now, before you start your work? The only roadblock here is that the Server software is not yet available. But if they're all independent programs, running stand-alone apps wouldn't be such a bad thing, right?

J

[metroart]

Yes, it's all stand-alone stuff, so I bought the upgrade to 7. And yes, it's a b**ch. To get it to work, you have to study the layouts, scripts and relationship graphs for the sample template that matches your app the closest -- you're on your own -- none of these are commented -- then read all the gory details in the onscreen Help file (the printed users guide is just an overview). And even then, all sorts of stuff still doesn't work like I thought it would/should -- e.g. one of my portals doesn't show any data from the related records and the portal that does show data won't summarize the fields, even after I construct summary fields exactly as described in the Help file for "Summarizing data in portals". BUMMER...