SeedCode Support Forum

I've asked this question here before, with no answer...

I know from experience that this forum is not short of brilliant FMP guys, especially John. So, I'm not sure if this missed the radar or what, so I'm going to try it again.

I know that there has to be a solution to this problem.

Here's the situation:

Developer creates FMP solution
Developer sells solution
3 months later, Developer has fixed bugs
Customers have been filling solution with records for 3 months
Solution is a complex database, with hundreds of Table occurances
Developer needs to issue updated solution to Customers
Customers download updated solution
Customers now need to transfer all their records to the new, updated version of the solution.

HERE IS THE PROBLEM

I'm thinking that this has to be an issue that EVERY developer must face. Therefore, there HAS to be a simple way to import all records from all tables, and reset auto enter serial numbers (very critical considering these serials are the basis for most relationships).

Plug in?
Function?

Please help, someone. I just can't imagine the answer is to create a script for each of the hundreds of tables.

??

Thanks in advance.

Nate

Nate,

You are right in one thing, this is a issue every developer must face when deploying updated versions of sulutions they create.

Nate wrote:Here's the situation:

Developer creates FMP solution
...
Customers download updated solution
Customers now need to transfer all their records to the new, updated version of the solution.

HERE IS THE PROBLEM

That is indeed the problem in a nutshell, although this problem exists in any solution, not only those sold as packaged downloadable products.

There are unfortunately, no easy answers. FileMaker has given us some fantastic tools, and a scripted import is not as difficult to create as you might think, especially since you know exactally what solution you are importing from.

Also I want to clarify one thing, just to make sure everyone is aware, it may seem basic, but even the best of us miss the basics sometimes.

Nate wrote:Solution is a complex database, with hundreds of Table occurances

...

Please help, someone. I just can't imagine the answer is to create a script for each of the hundreds of tables.

You mentioned tables and table occurances interchangably. You may be aware, but others may not, that you only need one import for each table, not each table occurance.

This may not be a lot of help, but it is worth mentioning.

For some more actual help, I can offer the following suggestions.

Seperating structure, interface, and data can greatly simplify the upgrade process. With clever development (in advance) it is quite possible to deploy almost any new feature, and just let the user keep their data file (with it's all so important tables) while using your new interface file or files. This solution means that no import is necessary.

If you want a much more involved solution, and one not without it's own expense and overhead, you could consider SyncDek (http://www.worldsync.com/syncdek.html). They have a version update management feature that would do just what you want.

I hope this helps, and I will talk to the guys at WorldSync and see if thet want to chime in on the discussion.

Court

Thanks for the response, Court.

Seperating structure, interface, and data can greatly simplify the upgrade process. With clever development (in advance) it is quite possible to deploy almost any new feature, and just let the user keep their data file (with it's all so important tables) while using your new interface file or files. This solution means that no import is necessary.

It would be great if you could elaborate on this a little more.

Keeping in mind that in the refinement of a solution, fields will be added and changed in existing tables, I'm not sure how you could avoid any import like you're suggesting. Unless, you're thinking that any new/changed fields/tables would be new tables with a new file reference...but, I would think that would make the structure messy if you've got new fields that SHOULD be in tables that already exist in their "old" data file (the one we're trying not to disturb.)

I can certainly see how replacing just the "interface" file in upgrades, and then having the user adjust the file reference for the "data" to link to their old data file would allow you to avoid imports on interface related improvements, or even new table additions. It's really just the existing field changes and existing table modifications that I'm hung up on (which seems like it would be the bulk of any data related improvments).

Am I missing something?

Nate

Court, John, others...

Has anyone used Update Genie by Hi-Voltage to accomplish this objective?

Nate

I haven't, but I really like their work.

(FWIW, I emailed the folks at high-voltage about this and they let me know that UpdateGenie has been discontinued.)