Database Programming, Can't rebuild indexes on pdox table

Can't rebuild indexes on pdox table

Author	Message
Greg Butle #1 / 5	Can't rebuild indexes on pdox table Every time I see anyone post a message asking how to fix a corrupt index or how to fix and 'index is out of date' error, the answer is always to either use TTable.DeleteIndex and then TTable.AddIndex or to use DbiRegenIndexes. Maybe I'm trying to use them incorrectly but these simply don't work for me. What am I missing here? If the index is out of date, you can't open the table in a TTable, you immediately get the 'index is out of date error' so that prevents the use of any TTable methods for working on that table. I get the same exact error message when I try to use DbiRegenIndex or DbiRegenIndexes. I have not yet found a way to rebuild an index once it gets out of whack. This seems like such a common, basic need, why isn't there a way to do it? If I had advance knowledge of the indexes for the tables I could just delete the files using a simple file delete and rebuild them but that's not the case for me, I need to be able to query the indexes to find out how to rebuild them. So far I have only thought of two ways I haven't had a chance to try out yet. One : read in the header of the .DB file, get the structure ID, write this ID to the header of the out of date index, which will fool the BDE into thinking the index is valid, allowing me to open the table, then regenerate the indexes using DbiRegenIndexes. Two : Use TUtility.DLL TUFillCRTblDesc to fill a CRTblDesc record for the table, then read the pidxDesc part of the CRTblDesc to get index info. Delete all the index files, then create them based on these index descriptions. I tried to get the index information using DbiGetIndexDescs but again since I can't open the table it fails with an error. Yes I tried using TUtility TURebuildTable to fix the index problems but the verify function reports no errors. Then if I force a rebuild anyway it fails with a message 'OS error'. I tried a couple freeware components/units that use TUtility and they gave the same or similar errors on any table I tried to fix. This is using Delphi 1 and 16 bit BDE that came with it and the corresponding TUtility version (2.52 I think?). I found that when I used a 32-bit repair tool based on TUtil32.DLL it worked just fine. If anyone has any solution to the problem, PLMK. If anyone else is looking for the answer like me, send me an e-mail and I'll keep you informed when I find a solution. -- Greg Butler XTI, Inc. Austin, Tx
Tue, 08 May 2001 03:00:00 GMT

Sundial Service #2 / 5	Can't rebuild indexes on pdox table Quote: > If anyone has any solution to the problem, PLMK. If anyone else is > looking for the answer like me, send me an e-mail and I'll keep you > informed when I find a solution. You're zipping right down the primrose path that we are taking with ChimneySweep? 3.0 or perhaps 3.1. (30 is now in beta test.) There are two related problems here. One is what to do when indexes go out-of-date. We can put those indexes back in place, literally in seconds. We can verify and repair a one-million record "table from hell" in less than nine minutes. Our release will include an OCX control and a Paradox plug-in to do this. (Before you ask... "by Christmas.") The second problem is capturing and rebuilding information like indexes, passwords, and referential-integrity automagically. That process involves capturing and acting-on more information, but with our script-driven technology we have the means to do that and this is in active development. It's a wild world we live in. -Mike Robinson "ChimneySweep" is a trademark.
Tue, 08 May 2001 03:00:00 GMT

Paul Motye #3 / 5	Can't rebuild indexes on pdox table I'm not sure I understand. Regenerating indices is easy! Steps: A. if the corrupt index is NOT the primary index: open the table using the primary index then DbiRegenIndexes will work. B. if the corrupt index IS the primary index: much more interesting. Delete all indices using DeleteFile or similar. Then create the indices one by one (primary first) using AddIndex(). Obviously, you need to know the details of the indices: I just store them in a text file. Paul Motyer SoftStuff PO Box 637, Croydon, VIC, Australia, 3136 Quote: >Every time I see anyone post a message asking how to fix a corrupt index >or how to fix and 'index is out of date' error, the answer is always to >either use TTable.DeleteIndex and then TTable.AddIndex or to use >DbiRegenIndexes. >Maybe I'm trying to use them incorrectly but these simply don't work for >me. What am I missing here? If the index is out of date, you can't >open the table in a TTable, you immediately get the 'index is out of >date error' so that prevents the use of any TTable methods for working >on that table. I get the same exact error message when I try to use >DbiRegenIndex or DbiRegenIndexes. I have not yet found a way to rebuild >an index once it gets out of whack. This seems like such a common, >basic need, why isn't there a way to do it? If I had advance knowledge >of the indexes for the tables I could just delete the files using a >simple file delete and rebuild them but that's not the case for me, I >need to be able to query the indexes to find out how to rebuild them. >So far I have only thought of two ways I haven't had a chance to try out >yet. >One : read in the header of the .DB file, get the structure ID, write >this ID to the header of the out of date index, which will fool the BDE >into thinking the index is valid, allowing me to open the table, then >regenerate the indexes using DbiRegenIndexes. >Two : Use TUtility.DLL TUFillCRTblDesc to fill a CRTblDesc record for >the table, then read the pidxDesc part of the CRTblDesc to get index >info. Delete all the index files, then create them based on these index >descriptions. I tried to get the index information using >DbiGetIndexDescs but again since I can't open the table it fails with an >error. >Yes I tried using TUtility TURebuildTable to fix the index problems but >the verify function reports no errors. Then if I force a rebuild anyway >it fails with a message 'OS error'. I tried a couple freeware >components/units that use TUtility and they gave the same or similar >errors on any table I tried to fix. This is using Delphi 1 and 16 bit >BDE that came with it and the corresponding TUtility version (2.52 I >think?). I found that when I used a 32-bit repair tool based on >TUtil32.DLL it worked just fine. >If anyone has any solution to the problem, PLMK. If anyone else is >looking for the answer like me, send me an e-mail and I'll keep you >informed when I find a solution. >-- >Greg Butler >XTI, Inc. >Austin, Tx
Wed, 09 May 2001 03:00:00 GMT

Markku Nevalaine #4 / 5	Can't rebuild indexes on pdox table Quote: > This is using Delphi 1 and 16 bit > BDE that came with it and the corresponding TUtility version (2.52 I > think?). I found that when I used a 32-bit repair tool based on > TUtil32.DLL it worked just fine. I didn't get, if your problem is D1 specific or not. You could try one more freeware utility, Fixit, from Delphi Super Page. Works at least with D1, and maybe with newer version also. It does just what you suggested. Save the structure of the indexes to an INI file. After this, you can totally delete or smash all the index files, and Fixit will be able to recreate them. Markku Nevalainen
Wed, 09 May 2001 03:00:00 GMT

Robert Cern #5 / 5	Can't rebuild indexes on pdox table Just delete the index files (using DeleteFile not deleteIndex) before opening the table and then AddIndex. For DBase tables you must clear the MDX production flag in header (it is at offset 28 - check Delphi TI) and then the same as for pdox tables. Indexes files are usually named: <table>.px - paradox primary index <table>.xg? and .yg? - paradox secondary index <table>.MDX - dbase indexes <table>.NDX - dbase index -- ------------------------- Regards, Robert Remove leading aa when replying. NO QUESTIONS VIA EMAIL. IF YOU WANT ADDITIONAL INFO, ASK HERE. Quote: >Every time I see anyone post a message asking how to fix a corrupt index >or how to fix and 'index is out of date' error, the answer is always to >either use TTable.DeleteIndex and then TTable.AddIndex or to use >DbiRegenIndexes. >Maybe I'm trying to use them incorrectly but these simply don't work for >me. What am I missing here? If the index is out of date, you can't >open the table in a TTable, you immediately get the 'index is out of >date error' so that prevents the use of any TTable methods for working >on that table. I get the same exact error message when I try to use >DbiRegenIndex or DbiRegenIndexes. I have not yet found a way to rebuild >an index once it gets out of whack. This seems like such a common, >basic need, why isn't there a way to do it? If I had advance knowledge >of the indexes for the tables I could just delete the files using a >simple file delete and rebuild them but that's not the case for me, I >need to be able to query the indexes to find out how to rebuild them. >So far I have only thought of two ways I haven't had a chance to try out >yet. >One : read in the header of the .DB file, get the structure ID, write >this ID to the header of the out of date index, which will fool the BDE >into thinking the index is valid, allowing me to open the table, then >regenerate the indexes using DbiRegenIndexes. >Two : Use TUtility.DLL TUFillCRTblDesc to fill a CRTblDesc record for >the table, then read the pidxDesc part of the CRTblDesc to get index >info. Delete all the index files, then create them based on these index >descriptions. I tried to get the index information using >DbiGetIndexDescs but again since I can't open the table it fails with an >error. >Yes I tried using TUtility TURebuildTable to fix the index problems but >the verify function reports no errors. Then if I force a rebuild anyway >it fails with a message 'OS error'. I tried a couple freeware >components/units that use TUtility and they gave the same or similar >errors on any table I tried to fix. This is using Delphi 1 and 16 bit >BDE that came with it and the corresponding TUtility version (2.52 I >think?). I found that when I used a 32-bit repair tool based on >TUtil32.DLL it worked just fine. >If anyone has any solution to the problem, PLMK. If anyone else is >looking for the answer like me, send me an e-mail and I'll keep you >informed when I find a solution. >-- >Greg Butler >XTI, Inc. >Austin, Tx
Wed, 09 May 2001 03:00:00 GMT

Page 1 of 1

[ 5 post ]