Managing data sources

[Greg G]

I have a DB that will be deployed as a runtime and is made up of one front end file and 5 files for data. So far everything works great but I am stumped as to one issue. 2 of the data files can only be used for a single project at a time. The rest are for persistent data that is not project specific. This means that the user can only work on one project at a time.

So how can I arrange it so the user can easily create and change projects to work on different things?

My current solution is a function I created that mimics the save/load procedure of software. It imports the project only DBs into container fields and exports them to a user defined location. Then the user can automatically delete all of the records to start a new project. It can then be used in reverse to import those same files from the user defined location and export them back into the proper location to work with the Runtime copying over the existing files.

I would love to have a more streamlined solution to this such as a way for the user to be able to create new projects (new blank DB files) and then to able to select which project from a list to work on. Basically being able to automatically define which project DBs the Runtime will access for data.

I hope this all makes sense. It makes my head spin a bit.

Thanks!

[Fitch]

I'd think about modifying your solution so you can work on more than one project at a time without juggling files.

If you really, really insist that those two data files can only have one project at a time, then I'd make two corresponding archive files, with scripted data imports and exports. That should be somewhat more straightforward than the method you described.

[Greg G]

Thanks for comments Fitch. Unfortunately I don't think have a choice about the 2 DBs being used for 1 project at a time. It is just not feasible based on the nature of the data and how it's used. Any given project can have upwards of 2000 records and the full ability of FMP's filtering and sorting etc etc are needed. The BDs would get excessively large and I would loose flexibility in dealing with the data.

That being said, can you elaborate on your suggestion? Are you suggesting that I have two background files that I can import/export to and from and some how store multiple projects in each one? I think this sounds good but I'm just not sure how to deal with extracting the right set of data when importing.

[Greg G]

Well I have explored what I think your idea entails. Basically I would need to import the data from each table in the 2 DBs to their respective background file table by table. Then to work on another project I would need to go through each table in these background files and do a find for the records associated with the required project and then import them table by table into the main files.

I'm not sure that this simplifies the process. I'm getting the feeling I just can't do what I want. The ideal solution would be to script the path of the data sources. Maybe in FMP 27.

[Fitch]

1. 2000 records is no big deal. Excessively large? Does it need to fit on a 400k floppy or what? :

2. How many tables does each file have? It's not that hard to script a search and import.

3. I'm still not convinced this whole archive idea is really necessary. Can you give me a specific example of a process or result you need to achieve that you think would not work with more than one set of project records?

[Greg G]

Hi Fitch. Thanks again for the comments.

1. 2000 records is no big deal. Excessively large? Does it need to fit on a 400k floppy or what?

I realize that 2000 records in and of itself is not a lot. What I'm concerned about is when there are 40, 50 or more projects that have that many records. Also, even though I strongly discourage it, I know some are going to put files and images into container fields not using the reference option.

2. How many tables does each file have? It's not that hard to script a search and import.

There are just over 30 tables in each file.

3. I'm still not convinced this whole archive idea is really necessary. Can you give me a specific example of a process or result you need to achieve that you think would not work with more than one set of project records?

Well I'm not convinced either which is why I am asking but I am also trying to keep in mind how much time different methods will require. With a couple hundred layouts (and growing) and as many scripts that perform various levels of sorts, finds, summaries etc., I'm concerned about the time it would take to retool it. In my limited experience I also don't want to corner myself if later I need to do something that would be made difficult by having multiple projects in the DBs. You have to understand that I am no expert at this. I am also trying to let it be as flexible of a solution as possible. One example is how to give the user an easy way to go to find mode in any of the over 200 layouts and perform any kind of find without actively having to deal with filtering for a specific project too. I know they won't want to have to worry about that. Idiot proof is my goal. As soon as someone accidentally shows all of the records and gets confused, they will get angry.

Thanks,

[Fitch]

Here's another possibility: use a plugin such as Troi File to rename files. This method would avoid any archiving or import/export.

As for container fields, you could move those to a separate file perhaps?

Now about your example, if you script the Find, the user can enter anything they want, and after they click continue, you can insert the current project ID and proceed with the Find. You will have to fairly tightly control the UI, but I don't know to what extent you may already be doing that.