Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
What if .cdx goes south and we have (had) Primary Key?
Message
From
19/08/1997 16:00:09
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Other
Title:
What if .cdx goes south and we have (had) Primary Key?
Miscellaneous
Thread ID:
00045638
Message ID:
00045638
Views:
77
I'm trying to write a general purpose indexing routine generator, about the same way I wrote these things ever since 1989, and I'm stuck with a problem. The strategy was always to create indexes from scratch. Damaged index can't be open anyway, and a damaged structural index may prevent opening the table itself. So I had a routine to null the "has cdx" byte in the table header, then deleted the .cdx file, and then opened the table exclusively and indexed. In FPx2.x it worked like a charm. Now, in VFP, the primary key gets in the way. If I erase the "has cdx" byte and delete the .cdx, I can't even open the table, because it breaks with error=1576 (I think) and issues an ugly alert box stating I'd better Validate Database. The only way to circumvent this behavior, AFAIK, is to do things in this order: erase the .cdx open the table low-level delete the HasCdx mark nullify the dbc info from the table header close the table (LL) set up all the indexes open the table (LL), restore the .dbc info, close alter table ... add primary key ... This involves two low-level writes to the table, and probably the last "alter table" is due to cause another error, since VFP is probably bound to check the existing primary key. I can't just Alter Table ... Drop Primary, because this indexing routine is designed to work even if the ..cdx is damaged or missing; Drop Primary also needs to have a proper key and a sound .cdx, otherwise it also requests Validate Database. In the days of 2.x I didn't care if anything happened to the .cdxes, because indexing created new and shining ones every time; now with dbc/primary key combination it doesn't seem to work anymore. The whole thing seems to be far less stable than it was. I've outlined couple of possible catastrophe scenarios: - bad .cdx, can't open table (missing primary key, Validate Database) - bad .dbc, can't open anything - table restored from backup or brought from another machine, won't open if its .dbc is absent - table restored from an older backup, when it had some other key - won't open. The worst is that some of the Vali Data options work from command window only; in an .exe there's none. Not to mention that I don't want any english text to appear before my user's eyes. Most of them know less than 20 words of the language and can't even read them properly, and why should they? It's my job to supply proper messages in their language(s). So, any solution to this... doommare which involves system messageboxes is unusable. Hints, anyone?

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Next
Reply
Map
View

Click here to load this message in the networking platform