Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Making a new release
Message
From
24/09/2002 13:46:52
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00702194
Message ID:
00703886
Views:
12
>What I am thinking about doing is, that, I could copy all the files in the Central folder to the Production/Test folders irrespective of, whether they are already in these folders.

>- Can I use the 'Copy File' to copy these files?
>- Will this corrupt the tables? or cause index files mismatches?


Ria:

Eventually you probably would have a problem with your index files if one of the fields changed was in an index.

I deal with the problem of users upgrading from older versions and I know some tables have been changed. I also know that when the old files are updated to the new structures any old data has to be converted to the new format. I might add, this is all done in a .prg because doing it manually is out of the question. Anyway, I go through the following steps:

(1) Check for the existence of the old file. If there is none then I simply copy the new file to the appropriate directory.

(2) If there is an old file I copy the structure to an array using ADIR and copy the structure of the newer file to an array using ADIR. Then I compare the two arrays.

(3) If there are no differences I leave the old file as is.

(4) If there are differences I backup the old file, copy the updated empty structure into it's palce, then append from the backup of the old file into the new structure.

(5) When all is completed I reindex everything based on the assumption that I may have changed something important.

(6) Sometimes I want to make sure a file is converted so I code a special routine that simply backs up the old data and copies the new data into its place. An example is the file containing credit card BIN numbers and card types, I always want the latest version of this information installed and know the users have no reason to have made any changes of their own (and if they did then I can then say the program is OOP, or oops too bad).

There are 13 free tables in the application and the .prg that takes care of this is about 2,200 lines long (old FPW2.6 code running under VFP7, not OOP at all). It's a little tedious when a I add a new table to the applilcation because I have to go into this .prg and update it. More tedious because I don't do it very often so I'm always having to reacquaint myself with the program. In retrospect, I suppose a much smaller program could be written that was parameter driven with the names of the old and new files and the result would be a more general purpose procedure not requiring much effort when you add or remove tables. On the other hand, it works great and I've had very very few (if any that I can recall) problems with around 7,000 users who are updating all the time.

In your situation if you aren't adding new tables then you could run something like this every day, or when you need to, and you would be pretty much home free.

Hope that helps a little,

Scott

Scott
Scott Ramey
BDS Software
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform