Arev 1.1 records only reached by key from screen (AREV Specific)
At 07 JUN 1999 04:42:03PM Carrol White wrote:
We have a corrupted file with usless backups.
I have file copied all but one main inventory file to a very old version of backups.
This inventory file gives a "variable length exceeded" error when you try to use a search, report, or even record count.
This file will pull up a record into the Window if you use the primary key.
Any possibility of recovering even part of these records?
I have placed this corrupted file in a seperate C:\arev\restore directory and all other files have now been copied into the working directory of C:\arev.
Thanks for any further help on this once large disaster, now smaller but still a disaster.
Thanks,
Carrol
At 07 JUN 1999 08:55PM Victor Engel wrote:
I suspect you are running into a problem with a rightdex or quickdex. If one was added to the file, an index record of all records on the file will be created and stored in a record names %RECORDS%. If the list of keys on the file exceeds 64K you will get the message you described. Restoring an old file will not make a difference if the old file is also over the limit, unless you also restore the related REVMEDIA.* files. But if I'm right, you should not need a restore at all. Just take the quickdex/rightdex off the file, and that should resolve the problem.
At 08 JUN 1999 09:45AM Warren wrote:
Along with Victor's suggestion of removing the quick/rightdex on the file you might also try deleting the %FIELDS% record in the dictionary as this may have become corrupted. After deleting the record, reattach the file or exit ARev and start it up again and it will rebuild when you access the dictionary.
At 08 JUN 1999 12:06PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:
Best thing to do is create a new file. Then, write a program which does a simple rbasic select, read in the record, write it to the new file, then delete the record from the orig file. Sooner or later, the file will probably shrink down small enough. If nothing else, the new file will be rehashed and possibly optimised some.
akaplan@sprezzatura.com
At 09 JUN 1999 03:34PM Carrol White wrote:
Thanks for the info - but I believe we have a real corrupted record(S) or records. Their hard drive was extremely full. Upon pulling up specific records it works fine (probably not hitting the corrupted record(s)).
The only indexing on these files are XREF. I have the file Xcopy into a C:\holdarev temphold with the name REV45000.*
Dump pulls up the front of file and says there are 6,441 records. List Temphold aborts, count records aborts, etc.
When I run a program just to read records it aborts with Illegal Operation and program will be halted. Totally shuts down AREV. I can run a program to recreate the key and read a record but how do I bypass these corrupted records?
Any further suggestions?
Thanks, Carrol
At 09 JUN 1999 03:47PM Carrol White wrote:
Thanks, Should have given more information. The only indexing on these files are XREF. I have the file XCOPY'd into a C:\holdarev temphold with the name REV45000.*
If I pull up specific records by key it works but I am probably not hitting the corrupted record(s). Their hard drive was extremely FULL.
Dump pulls up the front of the file and says there are 6,441 records. List Temphold aborts, record count aborts, etc. No Dictionary so that is not the problem.
When I run a program just to read records it aborts with Illegal Operation and the program abort shutting down AREV. I can run a program to recreate the key and read a record but how do I bypass these corrupted records?
Original Error: RTP57A line 168 B703 Variable exceeds maximum length. Line 168 'RTP57A' broke beacuse a run time error was encountered.
Thanks, Carrol
At 09 JUN 1999 03:57PM Carrol White wrote:
Warren, Thanks for the info but this is still from my earlier problem and I now have all the files moved but this inventory transaction file.
Their disk drive was FULL and I believe that along with basic parts of Arev this data file has some garbage in one or more records.
This file has been XCOPY'd into a C:\holdarev temphold with the name REV45000.*
Dump pulls up the front of the file and says there are 6,441 records. List Temphold aborts, record count aborts, etc. No dictionary so that is not the problem.
When I run a program just to read records it aborts with Illegal Operation and then aborts shutting down AREV. I can run a program to recreate the key and read a record by key but how do I bypass these corrupted records?
Original Error: RTP57A line 168 B703 Variable exceeds maximum length. Line 'RTP57A' broke because a run time error was encountered.
Thanks for any further ideas, Carrol
At 09 JUN 1999 05:55PM Warren wrote:
You said the disk was full. Was this the cause of the original crash or did this happen during the merge of the archived data?
If the latter I'd suggest just redoing the merge from backups (hopefully they have copies of everything prior to the restore/merge) and making sure there is plenty of free disk space first.
Running out of drive while writing to ARev files can seriously corrupt the files to the point of no repair.
At 10 JUN 1999 10:07AM Carrol wrote:
The disk full was the original problem. This client had done backups on a hit and miss basis (they know better now), but even the last backup was unusable so I had to go back several months.
All files except this one has been brought over from the corrupted AREV, with your help. So all other files have been saved. If we have to they will re-enter.
I thought of something thought - We have a master file for purchase sites and dates which is the first part of the key then the second part is just sequential numbers. Could I write a program to go through the master build the key and read those transaction and write those to a new file. When I hit a series that aborts then ignore that group. Might abort several times until all corrupted records are hit but might solve massive re-entry. Is this a possible solution? Any solution easier? Your Xcopy solution was wonderful and again THANK-YOU,
Carrol
At 14 JUN 1999 02:27PM Carrol White wrote:
Thanks to all of you, Final file retreived by writing a program to read the master file build the key by sequence until either a bad record or a number of misses, then went to the next master record and kept going. Eventually recovered most of the data.
Thank you, Carrol