Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Table has wrong location
Message
De
17/09/2010 08:52:01
 
 
À
16/09/2010 10:00:21
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 6 SP5
OS:
Windows Server 2008
Database:
Visual FoxPro
Divers
Thread ID:
01481161
Message ID:
01481582
Vues:
65
Hi David.

>Thanks very much for your reply. I gather then that it would be unwise to, say, copy a good dbc record of another table (thereby getting valid but perhaps incorrect binary info) and change the location-tablename and referential integrity info (which I can read) to that of my problematic table.

Correct. If the binary bytes, especially those for the length, don't match the content, the record is considered corrupted. Now, that being said, you can programmatically change the content of the properties memo if you know the structure. Each property is formatted as a "record" within the memo as follows:

{L1} {L2} {L3} {L4} 1 0 {ID} {VALUE}

where {L1} through {L4} are the bytes containing the length of the entire property (not just the value, but including the binary bytes), {ID} is the ID code, and {VALUE} is the content (strings terminated with CHR(0)). For the table path, the ID is 1. So a typical entry for a table would contain (amongst other properties in the memo) something like:

25 0 0 0 1 0 1 dbfs\customers.dbf 0

if the path to the table relative to the location of the DBC is "dbfs\customers.dbf". The 25 indicates the entire length of the path property is 25.

So, write a program that opens the DBC as a table, finds the record for the desired table, and parses the properties memo looking for the "property record" for the path (ie. reading the first 4 bytes, converting to decimal using CTOBIN(), reading the property ID, and if it isn't 1, skipping ahead the length number of bytes to the next "record"). When you find the right one, replace the value with the desired path (including a trailing CHR(0)) and the length bytes with the length of the path + 8, converted to binary using BINTOC(). Not necessarily for the faint of heart {g}, but doable. I've written code to do this, but it's part of a commercial product (Stonefield Database Toolkit).

>I'll probably embarrass you by saying so, but I still remember a lecture you gave at one of the VFP conferences (10+ years ago-I think it may have been Minneapolis) on tableupdate() that really helped me understand what was going on.

Thanks. That'd be about 14 years ago: the Minneapolis User Conference in 1996.

Doug
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform