Kernel Errors 348 and 351

[Erich Geiersberger]

>A few weeks ago I wrote with a problem I was having with a 
>customer's corrupt db from an application that uses V4MD.  I am 
>seeing the same type of corruption with a db created today by one of 
>our bug-testers.
>
>I desperately need some help figuring out what could possibly be 
>causing the db to become corrupt.  This product has been released to 
>several hundred customers.  I need to find a solution before this 
>blows up in our face.
>
>The version of the V4MD.x32 installed is 1.9.8.  We would be happy 
>to upgrade to version 2.0.x, but I would like to get some insight 
>regarding what could possibly be causing the corruption.  The errors 
>do not go away when the dbs are opened in v2.0b9.  I may need a way 
>to _fix_ any corrupted databases, as it is quite likely that there 
>are customers with corrupt databases out there.
>
>Here is what I have found:
>
>I have installed Valentina Studio (v2.0b9) in an attempt to diagnose 
>the problem or repair the database.
>
>When I open the problem database in VS, I get following errors:
>
>
>    1) When I view one of the problem tables in the data browser, when
>    scrolling through the data, I get kernel errors 348 and 351.
>
>    2) When I attempt to "diagnose" the table, I get an error "348", but
>    the Table Diagnose Report says "All right!"
>
>    3) I can dump to xml without getting an error, but when I attempt to
>    load the data, I get a kernel error 19, or VS simply crashes.
>
>    4) I cannot dump to sql. When I do, I get kernel error 348.


I am not sure if this helps you but we have had problems with error 
351 during testing a project done with that version. As far as I 
remember we tracked it down to the following conditions:

- Client-Server database
- One client writes to a table with a flush on the end of the process
- A second client writes to the same table *during* the flush

It did not occur each and every time, just sporadically so it is 
possibly some timing problem.
We needed to test for a long time to produce it. You could see it in 
the server log. It produced a "VarChar error 351" and the database 
eventually became corrupt.

We decided to ship nevertheless since for our application the chance 
that this happens in real life environment is near zero. The project 
is out with about 1500 installations and no problems so far.

The table in question contained VarChar fields in german but I am 
quite sure that the error message points in a wrong direction in that 
case.

HTH
-- 
Erich Geiersberger

Media Connect Multimedia
Gratzmuellerstr. 1
86150 Augsburg, Germany

Tel:    +49 821/ 34752 - 0
fax:    +49 821/ 34752 - 49
eMail   erichg at mcmm.com
http://www.mcmm.com