metroart Posted April 18, 2004 Share Posted April 18, 2004 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 Link to comment Share on other sites More sharing options...
Reed Posted April 19, 2004 Share Posted April 19, 2004 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 Link to comment Share on other sites More sharing options...
metroart Posted April 19, 2004 Author Share Posted April 19, 2004 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. Link to comment Share on other sites More sharing options...
Reed Posted April 19, 2004 Share Posted April 19, 2004 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 Link to comment Share on other sites More sharing options...
Ender Posted April 19, 2004 Share Posted April 19, 2004 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 Link to comment Share on other sites More sharing options...
metroart Posted April 20, 2004 Author Share Posted April 20, 2004 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. Link to comment Share on other sites More sharing options...
Ender Posted April 20, 2004 Share Posted April 20, 2004 What's wrong with multiple files? I've got about 85 in my system ( Job security!) Link to comment Share on other sites More sharing options...
metroart Posted April 21, 2004 Author Share Posted April 21, 2004 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. Link to comment Share on other sites More sharing options...
QuinTech Posted April 23, 2004 Share Posted April 23, 2004 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 Link to comment Share on other sites More sharing options...
metroart Posted April 25, 2004 Author Share Posted April 25, 2004 >>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. Link to comment Share on other sites More sharing options...
QuinTech Posted April 26, 2004 Share Posted April 26, 2004 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 Link to comment Share on other sites More sharing options...
metroart Posted April 27, 2004 Author Share Posted April 27, 2004 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... Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 7297 days old. Please don't post here. Open a new topic instead.
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 accountSign in
Already have an account? Sign in here.
Sign In Now