How to export then reimport entire solution?

[Sandy R]

I'm about to deploy a solution and I'm at a lost for how to continue upgrading it (which may not be necessary, but I'd like to be able to fix bugs). The issue is as time goes by people will be adding data to their (single user systems..no networking involved) local data bases. I'd like to be able to export all of the data from their solutions, and then import all the record into updated versions (with bug fixes) of the solution. The question is: is there a brainless way to export all the records and then reimport them into another identical solution (with perhaps minor changes to scripts).

thanks...Sandy

[Fenton]

The answer to your question, "Is there a brainless way?" is a definitive "No." There are a few "brainy" ways. The first question is "whose brain?" By that I mean that a smart user can import the data themselves, and reset the serial number of each table to the next value. Those are the critical steps. But it is the rare user who can do this error-free; and it must be absolutely error-free.

So it looks like it's going to be your brain. There are a few possibilities.

1. Have them send you their files, you do the import and resetting, then send their files back. This is the way I handle many clients. We just do it in the evening, or on a weekend (if it's really extensive). If you have a fast internet connection it doesn't take all that long to send files (unless they are huge).

One advantage of this method, which I don't see mentioned much, is that it gives me a chance to look over their data, in a way which they seldom do, looking for patterns, places where data is not being entered correctly, where we might want to increase the validation to prod users. The downside is that if you do find problems it can take longer; and you have to get their files back before they can enter any new data. They also have to be smart enough to: 1. Not copy the files while they're running, and 2. Install them back where they belong, with no duplicates.

2. Create a custom "update" routine in your file(s). It's pretty much what you'd do manually. Import all the records into the new file, reset any serial IDs to their next value.

If the user is smart enough to handle the 2 sets of files, old and new, then it is not that complex. If, however, you want to totally automate the process, actually replacing his old files with the new ones automatically, it's more complex. The trick is to Save a Copy of the new files, after the import, with the name and location of the old files. This will overwrite them.

It's a little tricky to set up. You must do this on your computer, and test, as an error would leave them with unusable files.

When I've done it, I've used Developer to save a set of the files with modified names. So that while I'm doing the import and setup, I'm not always dealing with 2 files named the same. It's not necessary, but saves some confusion.

After setting up the import and serial steps in the renamed files, I'll toss the originals, and rename the others back (the originals were imported "from," so do not have the import script). In the end there is only 1 set of files (obviously), with the Update routine built-in.

7 has added a characteristic to the Import which is helpful, which is that importing from a closed file will import all records. That saves a step; and it allows you run this routine on files which do not have the Update scripts (otherwise you'd need to make sure they were showing all records).

The "old" files and the "new" files could each be in a separate folder. That way you can tell clients to just put the folders side by side, and run the routine. If there are several files, you can create a separate little file, which just runs the Update scripts in each file. This has the advantages that: 1. You can make a whole interface for it, with messages, and 2. You don't have to put any interface into the files themselves. [bruceR has a clever way to build in the routine into the files, with no interface, so it checks and runs itself when needed.]

3. Separation of data from interface. Search for this in the Forums.

If method 2 sounds like the direction to take, then let us know. I have some version 5 files which illustrate it. Hopefully they still work :-)