Hey Joe - Compact problem

[Langley]

Hey, Joe. I was working on that compacting maintenance program we talked about a few threads back. I ran into a problem and wanted to know if you have ever seen anything like it.

The program locates all my tables across the network (300+) and then attempts to compact them. The compact() method is supposed to fail when a table is open. Anyway, on one table the data was all jumbled up. I verified the structure and it was fine. In this particular table, almost every field is val checked with 'picture'. When I examined the val checks they were there, BUT... they had been moved around. In other words the val check for field 4 was moved to field 8, the val check for field 8 was moved to field 12, etc... The really odd thing is that the data was changed to match the jumbled val checks.
.
I've tried it several times with fresh copies of the table in question and the results are always the same. Other tables seem fine. I even used setExclusive() without effect.

Have you had a similar problem with compact()?


basic syntax inside a scan loop:

if not tablevariable.compact()
then (log failure)
else (report file size change)
endif


Any ideas?


Mac

mailto:langley_mckelvy@cd4.co.harris.tx.us

 

[Langley]

Okay - the table was apparently corrupt but TUtility didn't catch it. Apparently compacting it just aggravated the existing corruption to point where I could see it. I ignored TUtility's diagnosis and rebuilt it anyway, then ran the compact utility against it again. No problem this time.

Odd that it got corrupted in the first place, since it is a readonly table. Oh well, live and learn.
Mac

mailto:langley_mckelvy@cd4.co.harris.tx.us

 

[JoeNg]

Sadly, TUtility does not catch all the errors. Especially those with the record pointers all over the map.

I would make sure the tables are closed or no one has any locks on the table before I would attempt TUtility or compact. Also, I only do this after the data are saved to backup tapes first!

I sometimes get "false positive", ie, I would get a corrupted data error in my log file. But when I run it through Table Repair, it was fine.

By using TUtility and Compact together, I just hope to catch as much errors as possible. In your case, I guess you might say it's a success.

 

[Langley]

Yeah, I thought I was pointing at a mirror of my paradox network files (which I keep on my local PC for just such tests), but one of my aliases was pointing at the actual network. Of course, it was an important table and brought all my paradox apps to a screeching halt - lol. Anyway, I now place a full lock on any table before I try to compact it, and generate an error if the lock fails. Oddly, I got some 'unable to compact' errors on tables with no locks. I went and was able to compact them via restructure with no problem. Thanks for the code and the idea. Even when it give false positives it makes me do the maintenance manually.

One thing I noticed in the compacting module. When I used the TRY/ENDTRY as you suggested, the log file was filled with 'success' messages and no 'failures'. When I switched to an IF-NOT-THEN I got mostly 'successes', but some 'failures'. Maybe I had the syntax wrong, but it seems accurate now.

Thanks again,

Mac

"Strange women lying in ponds and distributing swords is no basis for a system of government" - Dennis, age 37

mailto:langley_mckelvy@cd4.co.harris.tx.us