WearsManyHats

As far as I know, you will need a second file and a key field(one for each room) and a relationship for each key field to the file containing the Room data. A second file would be easier for design reasons to contain the map. Once the relationships are setup you could also have a small portal for each room to handle the multiple employees situation, total number of portal rows matching total number of employees possible for that room. If you really don't want to make a second file(why not?) you migh try a "self-join" relationship between records but that's just causing endless design problems that don't seem necessary.

"Interface" and data do indeed reside in the same file in Filemaker Pro. I would not think in terms of deleteing the old file, in your situation, but instead think of it as migrating users to a new solution. There are various methods for "upgrading" to a new set of solution files, some of them are discussed on this forum. Basically you can export all data from all tables into backup files or you can setup import scripts in your new files to import the old data. One thing that is helpful is to think of all the files in your Filemaker Pro application as analogous to "tables" in sql. Only in this case each table can also have any number of custom user interfaces which you design. One highly recommended method is to use a single filemaker file(table) as the "front end" to the application and use layouts in that file with relations to all of the other files. This one front end file may have no actual use in terms of data but simply acts as the user interface to all of the data in the other files. Usually you would setup primary key fields in the interface file which are related to the keys in each of the other files. Otherwise, pick the file(table) which is central to the purpose of your application and design your user interface layouts there. That's some quick info on Filemaker...

Yes, but this assumes that you want to delete the old solution file(s). It seems a better practice to me to have a new version in its own directory/folder in case the user, for whatever reason, wants to use the old version of the solution. In that case it would be best to import the old data into the new solution files. I suppose you could have the user copy/duplicate the current solution directory and rename it as "Old Version", then place the new clone file(s) into the existing directory and let the clone files do their thing. Your method is definitely a good one. By having a defined directory where all files and sub-directories are known by the solution in terms of name and location, scripts can be made not to break. I'm just trying to decide how I want the user to "touch" this upgrade process.

Using the tips and ideas that BruceR and Dan mentioned it's clear that previous data can be updated into a new solution. It seems to me the key problem is how to provide the location of the old data files to the new version of the system so that the data can be imported. I've not used the import script step in a script before or I would know the answer to this question, but I take it you cannot provide the user with a file browsing dialogue from within Filemaker to allow them to indicate where their old files are located?

Thanks Dan. I took a look and Lo and Behold, there it is. It seems likely to me that this script step showed up in version 6 but I don't know for sure. I've been using Filemaker I think since version 4 but only recently considered trying to make a standalone app. This question of upgrading users to a new version of an app is a biggy as far as I can see. As Dan said, one of the problems of storing the data along with the interface and everything else. It seems to me that if Filemaker the company is serious about standalone solutions using Filemaker that they would take a look at making this easier for all involved. Just my opinion...

Greetings, I'm new to the forum but I was looking around for just this kind of information. Dan, you say you need to set any serial numbers to (max serial number) + 1. I can see the reason for this but I am not aware of how to do this with scripting. My serial number fields are set to "auto enter serial number and increase by 1". I always thought you had to go into "Define Fileds" in order to set this or change the current serial number. Is there a way to do this programmatically? Thanks, Bob.