Version Compatibility

[smtobias]

I have been approached by a client to update a system which was created by a friend. For the most part it is working well, but they need to add a couple of fields and update their forms. I had considered adding a couple of reports as well. Since they operate on a network and the changes cannot be made while everyone is logged on, I decided to copy the affected databases (without the records) to disk so that I could work on them at my office. While I was there, I noticed that they are using Alpha5 v 3. I thought I had that version on my home computer but apparently do not. I have versions 2 and 4, but no 3. I know that things are generally upward-compatible but not downward compatible. Would I encounter problems if I made these changes in v 4 or v 2? I don't want to waste my time nor cause any problems for the client. If worse comes to worst, I may be able to arrange to make the changes on-site at a time when the network could be shut down.

I am also concerned about what would happen to the data if I use the same name for the updated database and then copy it onto their network. Since it would have no records, would all of the previous records be lost? Would it be better to give it another name and append from the old database and then change the name back?

I would appreciate any advice someone could give me to insure that I don't cause more problems than I solve. I'm pretty new at working with something someone else created.

Thanks, Sylvia

[CALocklin]

RE: Version Compatibility

I'm not sure how compatible the different versions are. I have them all so I haven't been in your situation. However, for what little it's worth, I have made changes using version 4 that were successful in version 3 - it was a mistake but I got lucky. Hopefully someone else can be more definitive.

As for "copying the database", are you talking about actually copying the database or the table(s)? This could be a mixed bag of trouble. Of course, if you copy the tables which have the same name but no data, then your customer will lose all existing data. (Not good for customer relations!) However, if the database files (*.adb, *.alb, *.alm, *.alx) are copied and you DON'T change the table names, then all should be OK. On the other hand, changing the table names will change the names in the database files and render them useless with the customer's data. (Confused yet?)

My recommendation:
(1) First - MAKE A BACKUP OF THE CUSTOMER FILES! (Bet you've never heard that before!)
(2) Second, keep the table names the same and make sure you ONLY copy the *.dd*, *.se*, and *.al* files back to the customer's computer.
(3) If you change any indexes, you will need to copy the *.cdx file(s) as well. BUT, you will need to update the indexes at the customer's location after copying the new *.cdx file to get the record pointers updated.

[CALocklin]

RE: Version Compatibility

Oops! I just noticed that you need to add a couple fields. This creates a new set of issues - but not really difficult ones.

To update their tables with the new fields, you will need to create the new tables with the new fields and save them somewhere on the customer's computer and append the old data to the new table.

My recommendation is: (after the backup!)
1. Get everyone off the customer's computer while you perform the upgrade.
2. Copy the customer's tables (those to which you will be adding new fields) to another, temporary, table name. This can be done with a database copy operation or by simply renaming the files using Explorer. If you use an A5 copy operation, copying the data dictionary is optional but be sure to copy all the data. Double check the range to be copied to make sure there isn't a query active that may limit the number of records that get copied.
3. Copy the new table(s) with the added fields to the customer's computer. Make sure you copy ALL the files - dbf, cdx, fpt, ddd, ddm, ddx - and that you have zapped all the data.
4. Manually run an append to append all the customer's old data from the temporary tables into the new tables.
5. Delete the temporary tables once you are sure everything is working correctly.

[whanigsberg]

RE: Version Compatibility

Silvia,

Did Cal forget to tell you to backup first?

Seriously, the only compatibility issue I recall existing between versions 3 and 4 has to with the key_exist and key_unique functions. I belive the change came in at version 4.03 (just checked and that's correct).

So check the 4.03 readme. You will find key_unique() listed in the index.

Now, considering what to do about this, the implication is that the application might not work correctly under your version 4, especially if you entered or changed data during testing. On the other hand, it would work right under the client's version 3 so long as you made no use of key_unique in altering it.

Hope this isn't too confusing.

Bill

[smtobias]

RE: Version Compatibility

As usual, I appreciate your thoughtful and thorough response, Cal. Fortunately the client does make daily backups and I was going to suggest making one just before I did the conversion, just to be sure. It's one thing for me to lose my own data, but it would be in extremely bad form for me to cause a client to lose theirs - not to mention a bad business move. :) I talked with the owner of the company today and mentioned the possible compatibility problem. He indicated a willingness to upgrade to version 4. I suggested he wait for version 5 since it is coming out soon. These changes are primarily cosmetic and "wish list" items and are not critical. In fact, if the new subforms slow the process, he doesn't want them. Fortunately, they are upgrading their system to the fastest processor and largest size so that may not materialize.

Thanks again,

Sylvia

[smtobias]

RE: Version Compatibility

Thanks for your response, Bill.

You can rest assured that I will never (at least knowingly) use the key_unique or key_exist functions. I can't think of any valuable use for them although I'm sure others find them indispensible. At least all of those who use them will find this information valuable.

Best wishes,

Sylvia