<TBL>.MEMO_CHECK What does it do, and what

[mronck]

Hi Guys,

I have been writing a script which tests a number of tables in which memo-fields are present.
The script uses the method result=t.memo_check("v") to check whether errors occur in the memofield with regards to pointers etc.
If errors are found, the method t.memo_check("vp",.T.) is used to repair the errors found.

The results of this script seem to state, that errors of the category "Record 12345 past end of memo file" are being repaired, whilst errors of the category "Records 12345 freespace is occupied by data from record 12345" are not being repaired.

I have checked the documentation available and can not find any clues of what can be repaired and what can not be repaired. Does any of you have more information or experience with this ?

Furthermore, if such errors of the latter category can not be autorepaired, what would be the best way to get it done anyway ?

Kind regards,

Marcel

[Chad Chapman]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

Hello Marcel,

""if such errors of the latter category can not be autorepaired, what would be the best way to get it done anyway ?""

memo_check() has been a welcomed addition, but in my experience, not 100% successful. I have not run into the message you describe, but I have had situations where memo_check() basically does away with data in the memo field. I assume this is because things are real bad :-(

The Alpha community has been dealing with memo field issues long before *.memo_check() was available. There are two commercially available memo repair utilities, (I think one is called dbFix, I can't remember the other name) but I have not used either of them. Someone wrote a memo repair routine in A5v1 that I think is still available in the code archives. If memory serves me correctly, this routine steps though the contents of a memo field character by character and rejects non-displayable characters. I don't think this routine was the total answer, but apparently worked in some situations. I believe you can find some info on memo fields on Dr. Peter Wayne's web site www.learn alpha.com.

Approaches that I use:
DONOT do a compact until you do a *.memo_check(). Doing a db compact or table pack makes things worse if you have a corrupt memo file, usually ballooning up the *.fpt file. Unfortunately this is when we usually find there is a problem.

Make copies and run *.memo_check() to repair the file. This works in the majority of situations for me.

If *.memo_check() does not work, (in the sense of perserving the data), then I duplicate the table with data and check the new table. Sometimes this is all it takes.

If a simple duplication of the table with data does not work, then I will duplicate the table without data. At this point many will say to then append data from the existing table to the new table. This will usually fail when it hits the first record with the bad memo field. But this locates the first problem record (approximately). You can continue this process by then appending from the end of the table backwards, or trying the append by starting after the bad record. Many times you will find that only a record or two are bad, but of course at times there can be a lot of corruption.

However, I prefer to copy the records form the existing table to the new empty duplicate table via xbasic by stepping through the existing table record by record. This method can also choke when it hits a corrupt memo field, but in general I have had good luck with this approach.

The key IMHO, is to catch the problem early by using *.memo_check(). It is my experience that if you can catch it early, it is easy to fix. If you don't catch the problem and a lot of records are added after the corrupt record, and then a db compact is done, things can get really messed up.

The design of the database is paramount. Dr. Peter Wayne has a great article "Memo Fields that Work" (I think this is the name anyway) on his web site. There is also a wealth of info on memo fields here on the message boards but it is scattered around.

Also make sure you check your table indexes as well. Although the two issues can be totally seperate, ad hoc experience tells me that the two can be related or at least stem from the same systemic causes.

Also check out the discussions of optimistic locking. Cal Locklin wrote up a great article on this issue in the Alpha Newsletter a couple of months ago. Apparently this can greatly effect index and memo field issues.

And, or course backup, backup, backup.

Good luck,

Jim Chapman

[Al Buchholz]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

Chad

For a new guy, you're sure good with the memo fields.

Then I saw the name at the end of the message......

The only thing that I can add is that the cross-referenced/duplicate referenced memo fields represent an unrecoverable situation where one of the pointers has been lost and there is nothing that has retained that can be used to rebuild it.

Sounds like that is the case that Marcel has run into.

whilst errors of the category "Records 12345 freespace is occupied by data from record 12345" are not being repaired.

Marcel, I would expect to see 2 different numbers listed in the message that you posted. I'm guessing that you typed that message rather than cutting and pasting it.

A good explanation of memo field problems is available at http://www.dsalvage.com/

This product expects a different formatted pointer that what Alpha uses and is not able to fix the memo field problems in Alpha. Even though, the same logical problem exists. If the pointer is overwritten with some other data, it can't be recoverd.

[Chad Chapman]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

Hello Al,

""For a new guy, you're sure good with the memo fields.""

Fast learner........... I wish :-)

At my son's place for the weekend and found that being an AlphaHolic means withdrawal if I don't get my 'fix' for the day.

Jim

[mronck]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

Hi Jim, Al,

Thanks for writing this experiences down for me. I already experienced the same things. Jim, the software you are reffering to probably is dSalvage as Al also mentioned. I have a license of this, and it is designed (I believe back in 1993) to work with Alpha Four also. So, diagnostics work for Alpha .dbf files.
However, this was not what I was searching for.

Now that Alpha has released the memo_check() command, it seems important that more information is released as well about what it exactly does, and what not.
Memo fields can carry different kinds of damage, and it is of course very interesting to know what kinds of damage can be repaired with this command and what not.
The occurence of non ascii characters is only 1 kind of damage of course.

In my example, I did not use the real record numbers but rather examplary ones "12345" should give the clue... so
Al is right that in real life the numbers of course are different from eachother because another record took the empty space of the older record.
Whilst this may be irrecoverable, it does provide info about which record is the source of trouble, enabling you to simply delete it and rebuild pointerfiles.
So the method of copying records block by block to see where the source of the problems lies might not be necessary.

Basically I am looking for answers to the question about what the function memo_check() does, and more important, what it does not do. At this point, the information is missing in the manuals and helpfiles, but Ed Larrabee is on the case and will investigate as he promised me by mail.
And we all know that such an action will lead to results, so I think waiting for that is the best option, unless one of you has more info on this....

Kind regards,

Marcel

[mronck]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

This is the reaction of Paul Heiser, author of dSalvage answering to my questions why dSalvage could not repair the damage correctly. As already stated in this thread, it seems not only that dSalvage can not repair this kind of damage, it also seems that there is no other external tool available that can do the job, making it more important for Alpha to come up with a solution:


Marcel,

Thank you for your inquiry.

To begin with, you have done nothing wrong.

Memo Repair and memo scan deal with two entirely different things. Memo Repair makes sure that the
"next free block" pointer at the beginning of the memo file is correct. If it is not correct, the
DBF file will not open. dSALVAGE's Memo Repair corrects it automatically. Memo Scan, on the other
hand, looks at all the memo field pointers in the DBF to determine if they all point to valid
locations in the memo file. Any pointers that do not point to valid locations are documented in
the memoscan.txt file. This presumes, of course, that the format of the memo field pointers
adheres to the DBF file standard. In Alpha 4 there was no problem since the format of the memo
field pointers was consistent with the standard. But, for some reason that we are not aware of,
the Alpha developers decided to depart from the standard when they created Alpha 5 with the result
that they used the "null" character rather than the "space" character to left-fill the memo
fields. Since the "null" character in memo fields is not permitted in the standard, dSALVAGE
considers it damage. As far as we know, there is no file recovery software on the market that will
handle this situation and, therefore, there is nothing that we know of that will allow you to find
and repair bona-fide memo field damage in an Alpha 5 DBF file.

Paul Heiser

Regards,

Marcel

[mronck]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

Ed,

Did you find any answers already regarding this problem ?

Regards,

Marcel

[mronck]

RE: &lt;TBL&gt;.MEMO_CHECK What does it do, and w

bump