Implementing new version of shrinkwrap product

General support questions.
PostPosted: Sat Oct 15, 2005 2:41 pm
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
Posts: 160
Joined: Sat Nov 29, 2003 12:26 pm
Location: Columbus, OH
PostPosted: Sun Oct 16, 2005 9:39 am
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
Court Bowman, President
Cleveland Consulting, Inc.

http://www.clevelandconsulting.com/
PostPosted: Wed Oct 19, 2005 8:03 am
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
PostPosted: Wed Nov 23, 2005 12:06 am
Court, John, others...

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

Nate
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Wed Nov 23, 2005 5:02 am
I haven't, but I really like their work.
John Sindelar
SeedCode
SeedCode Staff
SeedCode Staff
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am
PostPosted: Fri Nov 25, 2005 5:33 am
(FWIW, I emailed the folks at high-voltage about this and they let me know that UpdateGenie has been discontinued.)
John Sindelar
SeedCode

Return to General Support

Who is online

Users browsing this forum: No registered users and 3 guests

cron
(855) SEEDCODE
[email protected]
Follow us: