Error 1064 in module 19

ngebhard

Hi everybody,

our customer gets the error 1064 in module 19 while trying to post a vendor order. I checked the partnerguide support archive and get the following hints:

19 DB_Err(1064) Err_DB_IndexNotFound 1064 #

Error 33832 in module 19 means: Err_DB_IndexNotFound
DB_Err(1064) is the same as Error 33832 (33832 - (32*1024))

This means that there is an error in an index of a table.
It is probably caused by disk/hardware failure.

Try to do an DB-test on secondary and primary keys and to deactivate and reactivate the keys.
On the long term you should check the hardware configuration.

Since I don't have any other informations I will try to see if a database-test will give me any help, but maybe someone has more experience and can give me some hints? I.e. which kind of hardware failure this could be?

The customer is on a 3.70 native-DB. They are working with terminal sessions.

Any ideas are very welcome.
Thanks!
Nicole

kriki

Try to do like the partnerguide support said:
-make a fob of the table.
-delete the secondary keys and save the table.
-import the fob to recreate the secondary keys

When I read the errormessage, that was the first thing that came in my mind to try.

If that doesn't work, make a complete backup of the DB. Restore it in another DB and put that one online instead of the old one.

ngebhard

The key-thing didn't work. The problem is that we get an error message while trying to restore the backup. Seems to be an honest problem..

kriki

Some different things to try:

1) did you restore the DB on another server/pc? If this works, your server-hardware has some problems. In this case you have to check or change some or all of the hardware

2) make a copy of the DB and work on the copy. Make a dataport to export (and later import) the table with problems. Make a fob off the table. Delete all secondary keys. Delete all records in the table. Make a full backup. Make a new DB. Restore the complete backup. Import the table with the dataport you created. Import the fob with the table with all it's secondary keys. (INFO : deleting and creating records in a table is a lot more faster without the secondary keys and takes less time when they created after all records have been created. This is the reason I let you delete the secondary keys for deleting and importing the records)

ngebhard

We found out that the customers enabled a hardware-cache. We suppose that this causes this problems (we already hat something similar a couple of weeks ago!).

I deactivated the keys of some more tables once again and then it worked. I was able to post the order. But the db-test shows some more problems. I guess, we need to export the tables to solve it. At least this worked last time! :x

Thanks for the hints again.

Greetz
Nicole