Table corrupted, after repair accessing Memo field says "Cannot open memo field" 1

[Rajesh Karunakaran]

Dear all,

We have a table with 4 Memo fields. It was corrupted somehow and we repaired it using a utility called 'Advanced DBF Repair' (my office has this since long). After repair, accessing the table appears to be completely okay.

But however the Memo fields are not accessible. When I press Ctrl+PgDn to open the Memo field editor, it shows "Cannot open memo field". In my form which handles this table, all those edit boxes becomes Disabled because of this.

I thought of dropping those fields, create again and copy values from our yesterday's backup whatever is available.
But, is there a more direct method to rectify in the current table itself?

How do we solve this?



Rajesh

 

[GriffMG]

Your solution is probably as close as you will get, look at the size of the .fpt file associated with
the table of interest - compare it with the back-up - if it is zero bytes... you've lost the contents
otherwise there is some info still there and a simple copy to xxx and zap and append from might fix it.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Rajesh Karunakaran]

Griff,

The size of the FPT (the file after I fixed it with utility) is not zero but considerably good. But, when I copied the dbf/fpt to another temporary database in another folder, the size came as 1kb. The Memo field is editable there, but the values in all records are blank (yeah! because the size is showing as 1kb).




Rajesh

 

[GriffMG]

Do you still have a copy of the table before you repaired it, perhaps you can copy that...

I think you may have to rely on your back-up to get most of the data, or as much as you can

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Steve Meyerson]

Hi Rajesh,

A long shot if it's important data and all else fails: I've used a hex editor to analyze the file to see how the data (if any) looks like.

For example, create a 1-record file with the same structure, add some data to the memo field(s), save it. Compare the damaged fpt with the new fpt in the editor.

If you're lucky, you'll find only a byte or two to add, change or remove.

Just a thought.

Steve

 

[Chris Miller]

But, when I copied the dbf/fpt to another temporary database in another folder, the size came as 1kb

What does this mean, it shrank when copying?

I think you'll figure this out, of course you can't expect the full memo contents from files that have a small fpt file. You can't just combine any fpt with any dbf, as the dbf has pointers into the fpt file and that has to match. As often not much changes, you can combine an old but large fpt file with the repaired dbf and could see many memo values again, but of course no new memo content.

What you should have kept is the corrupted file triple (dbf/cdx/fpt) as it was before trying any repairs. And what you should always be aware of is that repairs are not magic, if you have a small fpt file and expect a rerpair tool to figure out hard drive sectors containing the missing parts, that's not part of any repair tool I know of, repairs only happen within the bytes still in the corrupt files. we're not talking about technically corrupt files with missing sectors when we have table corruptions, that are also file corruptions and also lead to missing data obviously, but they have a totally different reason, i.e. hard drive corruption.

All that remarked, I just appeal to your logic. And Griff hits the nail, the best you can expect is to get old memo content from backups. Clearly that's the only way to get back memo contents, if the table corruption was not a result of a concurrent write access by two VFP clients as the "usual" table corruption is only, but by a hard drive failure, which can mean unrecoverable loss of many sectors, because of overwriting. And in the age of SSDs that's not recoverable as from magnetic platters, albeit when that was a possibility it always was an expensive service and not doable with software alone.

Chriss

 

[Dan Olsson]

I usually "fix" this kind of problems by copying the file to a new one.
When the copying stops because of the corrupted memo, I REPLACE all memos with "" on that row.
Then I continue to do the copying until the entire file goes through.
Of course some of the memo info is lost, but at least I can open the table correctly.

 

[Rajesh Karunakaran]

Dear all,

I tried changing the memo fields contents with '' but even though it did not throw any error, still I was getting the same error when tried to open memo field.

Finally, in current table, I removed all the memo fields and re-added them. Then I updated all the memo fields from my last back up files. Still I am not sure if there could have been a better way!

I think the method we adopt as a solution depends on how much the corruption is and of course the presence of a backup for update, if required.

Thank you all!


Rajesh

 

[Gerrit Broekhuis]

Hi Rajesh,

A good back-up is one thing. An Uninterupted Power Supply (UPS) is another.
These units may not be cheap, but can help preventing data loss.

Regards, Gerrit

 

[Chris Miller]

I'd put it that way:

Backups are mandatory, no matter if you're a company or just program for yourself.
UPS surely is another mean to protect your valuable data, it's more or less mandatory depending on the reliability and I kow power outages also happen in first world states, but the rise in protection isn't a big factor, it's much more important to do backups.

I'd also say ending with a file that's not allowing memo access in some records may just be the best state that tool could achieve without deleting such records and therefore also remove the perfectly healthy other fields of data. So do you think you were "betrayed" if that's the case?

If you don't have the original corrupted files, you'll never be able to see if a repair with other options would have a better overall result, though.
And you can't even give the vencdor of the repair tool a sample with which they may improve it. I know, many vendors of repair tools don't exist anymore, so that's only a minor help. But last not least you also lose the chance to have your own go at the files.

Memos are not encrypted, so you might get many contents just looking at the fpt in any editor. It's hard to assign the texts (if it is texts) to record numbers, but the structure of dbfs and how to translate the 4 byte pointers in the dbf to a section of an FPT is all documented.

Having a real world case of a table curruption is actually worth something, as it's likely future corruptions will have the same nature. That's also a reason to keep the corrupt file, even after a successful repair, to have a reference.

I can say I never had any memo corruptions at all, only index corruptions and header reccount mismatches. Maybe I was lucky, but besides backups you can also monitor the health status of hard drives and react before they become unreliable, which sounds like a reason when your fpt file became truncated or a copy of the file would resulöt in a shorter copy, that just means the original file couldn't be fully accessed anymore.

Or, as Dan describes it, a COPY TO (which is not the same as a bare raw COPY FILE) gets to a record it can't process and stops there. Which is (I assume) the point at which he empties memos and does a COPY TO...REST. Well, that requires a DBF healthy enough so you can open it, at least. Maybe not applicable, but you don't tell very many details about your case.

Chriss

 

[Steve Meyerson]

Gerrit's UPS suggestion is certainly not the ONLY method to deal with corruption, as he knows. There are probably as many methods as there are programmers and users.

The main advantage of UPS is it may be the best method to prevent corruptions in the first place. That's a huge one in my opinion.

Steve

 

[Chris Miller]

Well, well, the only corruptions I had, the table header and index corruptions, all were without a power failure, so no UPS would have helped with them.

the best method to prevent corruptions in the first place

Not at all. Ironically the best mehthod to not have any DBF defects is not using DBFs. No single thing prevents concurrent writes but a server database, which will always queue all changes made to data files and process them one after the other without concurrency problems, those are the only source of defects other than actual hardwar faults of drive sectors or flash memory blocks.

The only thing a UPS savces you from is data written in the last moments a hard drive has power to write most probably anything but the bits it's supposed to write because every electronic fails. This also, by the way, has becóme less vulnerable, as hardware is run on the low voltage cpower buffered in condensators, hardware needs lower power, so even in case of power outage you have things like incomplete written out buffers, which mainly will mean the header of a dbf and the end of a dbf file are usually out of sync, which means you have a file length differing from the reccount stored in the header of the first file block. On top of that you could have any wrong bytes in the middle of a file, often enough long stretches of 0 bytes.

Head crash or such things usually don't happen, as hard drives are less and less having a head writing but are SSDs, and even if you have the magnetic drives still cheaper per memory, these don't only come with detection of mechanical crashes by gyroscopes, when the power down they'll also automatically park their heads with the last power they have.

Chriss

 

[Steve Meyerson]

You're right, Chris. There are many many ways data can get corrupted.

I myself have for years & years always used a UPS for my computer and cannot recall corrupted data. My users with corrupted data did not use one. I convinced some of them otherwise.

Just my own experience.

Steve

 

[Chris Miller]

Fair enough, Steve, but it only covers power outage failures, nothing else.

Chriss

 

[Steve Meyerson]

True That! And/or voltage fluctuations, spikes etc.

 

[TamarGranor]

Good to remember that a UPS is also a surge protector and probably a better one than the individual power strips. I had a nasty power surge a year or two back (during a storm) and it fried one of my power strips (as well as a landline telephone).

If I'm remembering correctly, that was the same surge that tripped one of our breaker boxes off entirely. (Big house; we have two boxes of circuit breakers.) It was really weird when in a moment, half the power came back on.

Tamar

 

[GriffMG]

Always worth reading your input
Thank you

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Steve Meyerson]

Hi Tamar,

As you say, UPS absolutely better than power strips. I'm not an electrician, but my understanding is power strips usually have only a single MOV (I forget what MOV stands for) which might be useful only for a single spike which one might even know occured. After that it's useless.

My own breaker box has two current paths, so I can see why your loss could cover half the house.

All, FWIW?

Steve

 

[Gerrit Broekhuis]

Hi,

For what it’s worth I recall that our IT-company was asked to investigate a server restart after a power outage. It turned out that the electical installation was not maintained properly. Instead of 230 Volt our customer got 380 Volt.

The UPS we had installed monitored the power surge and logged the event properly. No damage was done to the server behind the UPS, no data were lost and the UPS survived the surge too.

The logging was important to prove the electrical installation had received 380 Volt. Knowing this it was quite easy to find and repair the fault and the company that had done the electical installation was responsible. They fixed what was broken and the UPS saved everyone involved a lot of money.

Regards, Gerrit