Rolling out new versions

[Matthew F]

I'm wondering how pro developers roll out an updated solution to existing users?

I have a large and complicated solution that involves multiple files with dozens of tables. It is extremely tedious and error prone to manually import data from users files into updated templates. I would therefore like to script this, but the import script step is somewhat limited. Fistly the import path must be hard coded. Also the import table name can not be set by a variable so I can not figure out a way of looping over all of the existing tables in the solution.

Is there no easy way to roll out new versions of a solution?

[bcooney]

There's no easy way, but honestly, once the import script has been written, it's a button click. Here's a link to a thread in which I posted a demo of my routine. I have lots of posts about upgrading runtimes on the forum, but the key points apply to full versions as well.

[IdealData]

You can $variablialise the import table - but not when you create the script originally....

When setting up the import file and field mapping you must specify a file manually, I agree. However, once the mapping has been created you can use a $var to specify the source file and substitute that for the manual specification.

I have used this, but only for "matching names" field mappings.

Try it.

[Matthew F]

Thank you for your replies and the link to the prior thread. The example file has some nice features.

ID, thanks for correcting me on the variables, I needed to read the help page on "Creating File Paths".

Still, I have some questions about the Import script step:

1. If you chose, "Perform without dialog" how do you specify the Source table?

2. Is it better to organize by "Last order" or "Matching Names"? I don't understand what "Last order" means if you have multiple Import steps in a single script and have selected "Perform without dialog".

3. How do you avoid making the user login repeatedly for each table import for password protected files?

[Matthew F]

BC, I noticed the ominous warning at the top of the import script of your example,

Warning- Because of cascading deletes, watch your import order. Always import parents, then children.

I'm afraid to ask this but what is a "cascading delete"?

I'm also wondering what sort database changes will create problems with the import script and how to deal with them. For example, what will happen if you create a new field? Won't this break the script if you use, 'organize by Last Order'? I'd assume that "Matching Names" would be better (unless a field definition has been changed).

[bcooney]

If a relationship has Delete this Record checked on the child side, it'll be deleted when its parent record is deleted. That is a cascading delete.

Therefore, if your import routine deletes records in a table, you might be also deleting records in a child table. So, import parents then children.

I always test the import/upgrade routine with each new release.

[Fitch]

Check out RefreshFM

http://www.goya.com.au/refreshfm

Really well-done product, I used an older version of it and it easily paid for itself in time savings.

[Matthew F]

Thank you all, that is some great advice. RefreshFM looks very slick. It appears to do everything I was looking for and more.