Possible to script Define File References dialog ?

[Chris Baumbach]

Is there any way to script the "Define File References" dialog (other than just opening it up)?

I've searched the forums and looked into as many plug-ins as I could find, but I haven't found the answer. Perhaps I'm just blind.

For all three of you who would like to know WHY I would ask such a silly question... I'm trying to get my head around the fundamental architecture of a multi-user, separated db solution. For absolutely no good reason in particular I'd like to separate the "data" file further, into individual data files on a per project basis (an individual user will be tracking similar data across multiple projects). The trick is that I'd like the solution to be able to create new projects (and thus project files), and keep track of how many and where all of the project data files are located. As far as I can tell, this involves creating a new "File Reference" for each new data file that is created, and so forth.

Now, I haven't managed to get any further than this so if someone wants to point out how backwards this whole idea is, please do so -- it will save me much anguish.

Thanks

Chris

Ok, acutally, the reasons I want separate project data files are: 1) to manage the process of "archiving" old data that is no longer necessary, 2) give the user the option of storing the project data file within the project folder (network), wherever that may be, 3) build in some measure of distributed-ness so as not to keep all the eggs in one basket, so to speak, and 4) graciously ignore the data files that the particular user is not concerned with.

More on #2 above: My goal is to produce a db solution that functions much like a typical desktop application, where the FMP layout and business files will comprise the "application" and the FMP data files comprise the "documents". In this sense, Filemaker Pro itself is the operating system, and the "Define File Reference" dialog analagous to the "File... Open" menu item in the desktop application.

</rambling>

[Ender]

I think it's a bad idea to go messing with file references to handle your archiving and separation of projects.

You should take advantage of the relational model and security model to limit access to projects based on whatever criteria you want. If the files are getting too large and you want to purge some data, archive it to backup CD or something, then import the still active records into a clone. Since you plan on using the separation model, this will be easier as the data that need periodic purging can be dealt with separately from data that should remain.

If the fields are the same, I would keep separate projects in the same tables. This makes maintenance and the interface much easier.

[Vaughan]

So, you end up with 300-odd files scattered around the place. It's easy entering little bits of data into 300-odd files scattered around the place.

Then somebody then asks you to make a report, on how much profit the 300-odd projects have made for the company over the past five years.

Think about the amount of work required to get all of that data from 300-odd files scattered around the place onto one piece of paper.

[Chris Baumbach]

Thanks for both of your comments.

Ender, I'm not so concerned about security, per se, just getting all of the irrelivant stuff out of a user's face (although one could do this quite easily without separate data files). And you're probably right that building some kind of archiving process into the application wouldn't be that much work, perhaps resulting in a better long-term solution for the users than worrying about separate files.

As I think about it, Vaughan, it's clear that you're right -- if there is any chance that I might want to report across projects then separating files is going to make it difficult if not impossible.

However, I still think there could be a valid use for a scriptable file reference feature. IF I wanted to build a solution that used the familiar application-document paradigm, the only way to "open a document" would be to script the file reference dialog to point the layout/business "application" to a specific data file "document". Right now the folks in my office use MS Excel to do what I want my solution to do. The typical user understands "double-click application, find and open project document", and I'm afraid that a true client-server database solution would put them off at this point.

It sounds like if I do want to build a true app/doc solution I should use a more typical programming development environment, and that a database development / management system is really meant for something different.

The more I think about it, however, FM is still the way.

Thanks again for your time and comments.

Chris