Transfer Files

[James Peterson]

We have written an application and installed same on clients's computer. Changes had to be made by adding several reports. No change in the table structure.

How do I transfer the updated database to the client's computer without effecting the data that has been entered in their program? I guess what I am asking is what files should I not transfer?

[Bill Warner]

RE: Transfer Files

Whenever I make a change for a customer on my computer, I sort the files by date, and send the latest files. However, a couple of cautions:

NEVER send the *.DBF or *.FPT, unless you intend to overwrite their data with yours.

Don't send the *.CDX (indexes), unless you have added or changed an index definition. Then, make sure your customer updates the indexes.

If they are on a network, and all you did was to modify a report or form, send the *.DD* files but NOT the *.ADB (which is always updated when you open the program, but does not affect forms, reports, etc. for a given table).

If you change a script for a network customer, send the most recent files to be copied to their server, and make sure they network optimize.

[csda1]

RE: Transfer Files

Bill,

What you say is basically correct, but let me qualify it a bit

For Table changes you want to send the tablename.dd* files

For Set changes you want to send setname.se*

For global script/function/menu/toolbars you should send the databasename.al*

For additions or deletions of tables and sets, you must send the database.adb file

Finally, any saved operations (and if he has the non-runtime, layouts) by the user (typically queries) will be lost when you update the respective table or set data dictionaries.

Along these lines, I have a utility under development (called the A5 Updater) that will compare two databases, and update the appropriate tables/sets/database with only those items that have changed. I hope to have it available for sale in about a month or so, but since it mucks with the data dictionaries alot, needs to be thoroughly tested and debugged. It may also update/add/delete index definitions (not too difficult) and with a degree of extreme caution, table structures (real tricky).

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[Steve Augeri]

RE: Transfer Files

I am interested in your update utility and when it is ready please notify me.
Steve Augeri

[Stephen Williams]

RE: Transfer Files

What would be useful would be to allow modification of table structure. This is tricky, so I would expect the process to go
1. Backup target tables, so we can restore fully if we fail.
2. Copy target tables with old structures to temp location.
3. Install new tables in destination (replace existing files)
4. Zap the new tables (in case there is anything in them)
5. Compare old tables to new, make a field mapping
6. Copy old data to new tables.

This way we have TWO copies of original tables - the backup made first plus the copy made to temp location.

The hard part is the compare (you seem to have a handle on that). The field mapping ought to be a relatively straight forward operation (though involved) given the compare works.

THIS would kick butt, and get my buck.

[Lowell Wardlow]

RE: Transfer Files

Ira -
Why couldn't you do a hash total on each file, and copy
just the ones that are different - excluding, of course,
databases, indexes, and memo files ?

This is basicaly what you can do with pcAnywhere's
file compare/transfer utilities, only it uses the file
date for the comparision.

Just a thought.

Lowell

[csda1]

RE: Transfer Files

Lowell,

Stephen's method is sort of correct for table updating, with a couple of details and issues missing (which is why it's more complex than it appears). If people used good programming techniques all the time, it would be a bit easier, but I don't want to count on that.

On your idea of just doing a file comparison:
I could just compare the files that are different and replace those with the new ones. But I have a 15 meg data dictionary files for just one set. Compressed, that's still 3 Megs. That's a lot to update for changing just 1 form. Plus, there are times I don't properly record all the changes I made, and may leave something out. Once you do a database compact, every data dictionary may be compressed, and two "functionally" identical dictionaries could be different on a byte-by-byte comparison. This will typically make every data dictionary appear different, resulting in all of them being updated. You might as well send them the whole app at that point.

But if I did as you said, the end-user will lose all his saved queries (which is possible in the runtime), and if he has the full A5 version, any report, letter or similar customization they may have made.

And updating the database structure (programmer's often need to add a new field, or change the width of something etc) is something that is difficult to do while maintaining all of the end-user's data and not losing any links. And there are times when you may want to convert some of the old data to a new format (which could be optionally done).

Does that explain why it's needed?

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[martinwcole]

RE: Transfer Files

I'll take two

[Lowell Wardlow]

RE: Transfer Files

Ira, I appreciate your thorough explanation, and would certainly use such a utility.

However, I am not clear as to whether it could be used to
update a client "online", since it appears that both the databases would have to be available for the comparison.

Can you let us know how this would be accomplished, or am
I just overlooking something ?

Thanks
Lowell