Ultralite i/o errors 200019 200020

[Former Member]

Hello everyone,

We have a very complex android application where we use Utlralite 16 and Mobilink 16 as DBMS/sync products.

The field has reported some I/O errors while using the device and despite looking at the documentation (http://dcx.sap.com/index.html#sa160/en/saerrors/errm305.html), we don't really get what can be the root cause of this and help would be greatly appreciated.

Those come in two flavors : - I/O Error 200019 - I/O Error 200020

The devices concerned still have free space on the disk and we ensure a device goes not to sleep by taking a partial wake lock.

Does anybody have any idea of what's going on under the hood / have already experienced such errors ?

[chris_keating]

The I/O Error 20019 is a read failure and the 200020 error is a write failure. Where are you storing the database?

[Former Member]

We're storing in a folder on /sdcard/<application-name>/. /sdcard/ is an internal drive on our devices.

Maybe another note : the app seems to run pretty smoothly on 3000 devices but we are experiencing this issue on a few of them.

[chris_keating]

When you say a few, what percentage would be failing? Could be a bad set of SD cards perhaps?

[Former Member]

I can't tell an exact percentage as we gathered bug reports containing those failures on, actually, 6 devices (out of 3K).

We can't exclude errors on their internal disk. But it doesn't happen systematically. When installing a fresh DB, it starts again as if the problem never appeared.

Could it be any other cause, i.e. locking ? Transaction not finished in a clean way ? Index refresh interrupted ?

[chris_keating]

It is an indicator that the database I/O has not worked during read and write. It may be that the database file has some sort of corruption and replacing the database resolves that corruption. If you have retained copies of the database from the problem devices, you may want to run ulvalid to check the health of the database file.

[former_SQLA_member1694876]

As Chris commented, these indicate a read or a write error -- meaning the system call returned an error code when UltraLite tried to read or write a page in the database or temporary file.

These do not indicate any database/SQL level issues, like locking or uncommitted transactions or indexing operations.

These do not necessarily indicate a corrupt database. When UltraLite receives the error, it will suspend operations on the database file in order to avoid corruption. When restarted, the database will recover to the last committed transaction. The error could be transient or recurring, depending on the cause.

Typically this is caused by some kind of hardware or file system problem.

If the application/database is restarted, does the error occur again? (Note that if you don't close and reopen the database, the same error will be reported on subsequent database requests because the database is locked. All open connections must be closed.)

The ulvalid utility can detect and provide information about some kinds of database corruption.

Historically we have seen many surprising problems with SD cards. It is probably worth trying a different card to see if it affects the error (if you are able to swap it on your devices).

[Former Member]

Mr McClements and Keating, thanks for your answers.

Actually, the application crashed due to a write error and then restarted. When it restarted, it crashed again due to a read error. We do not release all the connections when such a crash occurs. Just the concerned one. We will then try to do so and see if we can recover.