Last days it occurs. that I have had a error 512 on a ERP an one on a c4 System.

On the c4 system we did the following:

- repair int tbase6.1
- full convert to RDD
- full create RDD
- rorganize tables

and wie tried rc.stop and rc.start to take care about the shared memory manager.

Nothing helps. At least we deleted the table, and created it new, that helps. So we are lucky, because that was possible with that table without data loss.
BUT WHAT TO DO IF THAT IS NOT POSSIBLE?

So on the ERP System I can not delete the table! This problem still exist.
(ERP is with SQL 2000)


Thanks
Spartacus:confused:

If you have a copy of the old dd(dict/dd) for that particular table you can copy that into place and do a convert to runtime on that table with a reorg.

Spartacus,

When the error occurs, is it still possible to make a sequential dump of the table?
If so, in case of the risc of losing valuable data, you first can make a datadump, then delete the table, create the table again en import the data. Just make sure the data still is compatible!

Ofcourse it's important to note the remark of Nicholas, because I think it's the proper solution. We did it ourselves recently, and it works like a charm. (By the way, in this particular case we used the datadefinition of our testenvironment, wich was compatible with the data.) Fortunately, we were able to save the data first.


Henk.

I have had no copy of the old dd. But I'm so far lucky, that none of the tables contains very important data. So at hte moment I delted them and created new.

For sure no sufficient solution with important tables.

Besides from one of the tables I tied to create a seq dump, but that also doesn't work.

Spartacus

Spartacus,


Maybe it's an option to restore the datadefinition from an earlier backup? (Or, as in the case I described, from a testenvironment?)
Data perhaps can be restored from a previous database export?


That is, ofcourse, when regular backups take place, but I presume they do.


Henk.

In bugfixlist of newest portingsets I saw that several DB errors that were ignored in the past are now translated into 512...