When creating a runtime Filemaker creates 2 files, 1 the runtime, 2 the database data. Since I'm going through beta trials right now, is there a way to distribute new runtimes but not new database data files. I don't want to have to worry about asking people to import there old data into a new database.

When creating a runtime Filemaker creates 2 files, 1 the runtime, 2 the database data. Since I'm going through beta trials right now, is there a way to distribute new runtimes but not new database data files. I don't want to have to worry about asking people to import there old data into a new database.

When creating a runtime Filemaker creates 2 files, 1 the runtime, 2 the database data. Since I'm going through beta trials right now, is there a way to distribute new runtimes but not new database data files. I don't want to have to worry about asking people to import there old data into a new database.

well, you are getting into the data seperation issue and i would point you to the entire forum here for that discussion and debate. but outside of whether or not your system could structually do it....

yes, you can mix and match runtime files using the binding key. if you give them the same binding key when creating the runtime they will work together if you move the replacement into the same directory structure (replacing the old file, all with the files quit of course).

you will need to apply some intelligent tracking of the file versions and keep them out of each others way, but besides that, yes, we have swapped in runtime files with a matching name and binding key without having to recompile the rest of the system.

oh darn, just realized that all this knowledge is based on v6. i haven't done extensive runtime testing on v7 yet, but i haven't heard that this behavior/feature changed.

well, you are getting into the data seperation issue and i would point you to the entire forum here for that discussion and debate. but outside of whether or not your system could structually do it....

yes, you can mix and match runtime files using the binding key. if you give them the same binding key when creating the runtime they will work together if you move the replacement into the same directory structure (replacing the old file, all with the files quit of course).

you will need to apply some intelligent tracking of the file versions and keep them out of each others way, but besides that, yes, we have swapped in runtime files with a matching name and binding key without having to recompile the rest of the system.

oh darn, just realized that all this knowledge is based on v6. i haven't done extensive runtime testing on v7 yet, but i haven't heard that this behavior/feature changed.

well, you are getting into the data seperation issue and i would point you to the entire forum here for that discussion and debate. but outside of whether or not your system could structually do it....

yes, you can mix and match runtime files using the binding key. if you give them the same binding key when creating the runtime they will work together if you move the replacement into the same directory structure (replacing the old file, all with the files quit of course).

you will need to apply some intelligent tracking of the file versions and keep them out of each others way, but besides that, yes, we have swapped in runtime files with a matching name and binding key without having to recompile the rest of the system.

oh darn, just realized that all this knowledge is based on v6. i haven't done extensive runtime testing on v7 yet, but i haven't heard that this behavior/feature changed.

OK, so what your saying is I have to create another database file with all the user data on it and access in the main database. I was hoping I wouldn't have to wory about a many to many solution. No other way?

OK, so what your saying is I have to create another database file with all the user data on it and access in the main database. I was hoping I wouldn't have to wory about a many to many solution. No other way?

OK, so what your saying is I have to create another database file with all the user data on it and access in the main database. I was hoping I wouldn't have to wory about a many to many solution. No other way?

Heathbo

Part of my solution contains export and import scripts that will remove the old data into seperate files and import them into the new version of the database. This should mean simply providing a new database file for everyone, providing NONE of the runtime options are altered (not sure on this, but it has worked for me).

Also, I wouldn;t recommended messing with or chasing up file keys and suffixes, keeping old revisions. Its dangerous. Cleaner and simplier is the one application, one database file approach. Trash the old ones (add an applescript step to move file to trash, also easily done).

However, the snags are

(a) writing the export script so they go through EVERY table and export all ( i recommend exporting as fm7 for easy field matching, personally).

( then writing the import script to also go through EVERY table and import data. Its a chore but worth it.

© security - if you wanted to limit the beta/demo by number of records this ability sort of works around that. I do not activate this ability for the demo version and I would expect you to trust your testers, before giving them this ability.

Hope this helps in some way.

Heathbo

Part of my solution contains export and import scripts that will remove the old data into seperate files and import them into the new version of the database. This should mean simply providing a new database file for everyone, providing NONE of the runtime options are altered (not sure on this, but it has worked for me).

Also, I wouldn;t recommended messing with or chasing up file keys and suffixes, keeping old revisions. Its dangerous. Cleaner and simplier is the one application, one database file approach. Trash the old ones (add an applescript step to move file to trash, also easily done).

However, the snags are

(a) writing the export script so they go through EVERY table and export all ( i recommend exporting as fm7 for easy field matching, personally).

( then writing the import script to also go through EVERY table and import data. Its a chore but worth it.

© security - if you wanted to limit the beta/demo by number of records this ability sort of works around that. I do not activate this ability for the demo version and I would expect you to trust your testers, before giving them this ability.

Hope this helps in some way.

Just to clarify the steps

1) Run export step from current solution.

2) Remove old database to other location.

3) Quit solution

4) Install new database

5) Run solution with new database

6) Run import script

7) Trash old files.

8) Trash exported files (keeps it all clean!)

Just to clarify the steps

1) Run export step from current solution.

2) Remove old database to other location.

3) Quit solution

4) Install new database

5) Run solution with new database

6) Run import script

7) Trash old files.

8) Trash exported files (keeps it all clean!)

Now I'm running into the problem, How do I import data from one .USR file into another?

Now I'm running into the problem, How do I import data from one .USR file into another?

You have to open the current USR file in filemaker, export data.

Then code the export/import steps into your NEW database.

Import data.

Done

Does that make sense?

Then how does anyone perform updates. Say I add new types of content to the database. Well the old .USR file won't support that info. And since not everyone I distribute this to has filemaker, how does anyone perform updates? This is a Beta stand alone program. Filemaker isn't needed for the end user to use. But it is a beta, which means updates will happen. I can't import the .USR info from one runtime to another .USR file without filemaker, can I? Any help you can give is much appreciated.

I believe the runtime can perform scripted exports and imports. You just need to plan the process and provide the scripts.

Please pardon my ignorance, I am new to the Developer/Runtime world. How would I go about setting up the imports? Is there permissions I have to have set? Is there a peticular script that has to already be in the runtime?

This may seem obvious to most people, but as a novice, I've just been battling with how to do this. The manual says, "Open the original primary file (before it was bound) in FM Pro." Make changes, and send the new copy to users, asking them to replace the old file with the new one.

I'm not sure what the phrase 'before it was bound' really means. What I discovered you need to do is open the primary file that was created in your solutions folder (open it with FileMaker Pro). That is, not your original file (in Windows, the one with a .fp6 extension) but the file that was created in the run-time solution (extension .USR). Then you can make your changes (changes will be saved automatically when you close). The new file (.USR) will replace the old one and it should work fine.

The other option is to work with your original FM file (.fp6), to re bind it (with the same binding code and same primary file name). Then replace the old .USR file (in the orignal Solutions folder) with the new one. Either way will work.

I am new so haven't done much testing about what kind of structural changes this regime will allow. But so far I've added new layouts, and new fields and it works fine.

Obviously if you are working with FM4, 5, 6 and want to update to FM 7(say), then you will need to go down the 'exporting data--importing data' route. (so says the manual but I haven't tested any of this)

Also, if you make changes to any other files (ones that the primary one calls on (eg.look-up files)), then you'll need to repeat the above for each of these. Again, you'll need to test it all to see if your new structure can handle the changes.

Hope that helps a bit.

The problem is all the user data (ie. the info the users have put in themselves) is also stored in .USR file. So if I replace it, all the data they entered is gone. So I need a way to import data from the old .USR file into the new .USR file with the updates and changes. I refuse to believe I'm the only one who has had this problem. Could someone please tell me, how do you make updates to a runtime solution without loosing the data users have put in and with requiring the users to have Filemaker.

If there is no way, then this is a serious oversite on Filemaker's part.

First, I suggest you change the file extension from .USR to one of your own making. 'USR' is common enough that your users could have an app with the same extension. There is a web site that serves as a clearing house for both Mac and Windows developers to register their extensions.

You can transfer data between 2 runtimes using various methods. My preferred method is to export data as .mer files. You can easily create scripts in all files that have data. Each script should have a 'Show All' and then an 'Export'. You'll need to run through the procedure once by hand and then open and save the script (I don't know what V7 does, but V6 works this way). The new runtime will need import scripts to import the .mer files.

Alternatively, you can to a direct import between each new runtime file and its older version. The same methodology will apply. If you have a large number of files that have data, you may want to write a driver script that runs in its own file on startup and sequentially executes each import script in the data files.

Although it sounds complex, its more tedious than difficult.

Steve

Sorry for the bum steer, Heathbo. (I said I was a novice! ) I see what you mean. Well, this has just made my job much bigger!! Steve comments are cogent and applicable.

So how do I perform an import directly from one runtime to another? Do I have to setup anything ahead of time other than an import script?

The runtimes must have the same binding key. You'll need the Show All in the old file, the import script step, but that's all.

Steve

OK, I did that. Now I'm told my access privileges do not allow you to perform this action. Even when I log in as admin I still get that. By default, the solution logs in as guest.

The obvious answer is to change your access priveledges for the import that only you control. You probably have it limited to not import/export (this was available in V6...V7 is probably similar).

Steve

Or you can mark the script to run with full access privileges in scriptmaker.

Checking allow export in the guest account fixed it.

My next question is, how do you do a scripted import that will import data from multiple tables from a file the user selects. Inother words, I need to be able to let the user browse to where the old file is(to import the data) and with the same script import data from multiple tables without the user having to go through the import window?

I guess What I could do is, create a folder called "Put Old File Here" and then run through the import process a couple times in the script for the different tables in the old file. What do you think?

Any thoughts? Anybody?

Unfortunately, you do have to know where the exported files are. You cannot 'softcode' it. My solution is to ask the user to rename the 'My Brilliant System' folder to 'My Brilliant System Old' on the C-drive. (My user guide says that if you've moved the folder then move it back for the update.) The new version is loaded as 'My Brilliant System' on C-drive. All the import scripts in the new version point to 'My Brilliant System Old'. The main place I use this, the user has no choice but to use the C-drive; if they move it, that's their problem. There's a shortcut/alias pointing to the standard system. I put a switch in the new version which runs the import script when it's on.

Basically, the user runs a script in the old version to get ready (export to .mer files, get next serials, etc. ) then renames the folder. When the update arrives, the user just loads it (using an installer) and runs it. Bingo!

If you like, you can use WinBatch or Applescript to avoid insisting on having the folders in a standard location. (I'm too lazy.)