|
I have a base that returns the following message after executing a (select * from): Internal database error *** ERROR *** Assertion failed: 202000 (16.0.0.2043) Invalid string continuation at row 0x0 on page 0x15751 in file 0 - transaction rolled back SQLCODE = -301, ODBC 3 State = "HY000" I know there are corrupted records, but how do I identify them? thank you. |
|
Here's a general documentation from The SQL Anywhere Wiki how to deal with assertions: Have you validated the database? Do you have a current backup? May an index be corrupt which can easily be rebuilt? If you know that the rows of a particular table are corrupt, one possible way to find the corrupt rows is by trying to select a limited number of rows using an order imposed by the primary key or an index and then try to select rows until you get the assertion, such as SELECT TOP n * FROM MyTable ORDER BY ID; with increasing n, and possibly in a second attempt with descending order. But that is usually part of data salvage, i.e. when your restore attempts have failed. Thank you Volker Barth further in this way are there any other means of locating such records? if I know which page is corrupted is it possible to find out which range of records are within this page?
(13 Sep '18, 21:48)
gil
Replies hidden
I don't know and have never had the need to know that... what are you trying to achieve? A very very very wild guess: Possibly the ROWID function might be of help here.
(17 Sep '18, 03:38)
Volker Barth
> never had the need to know that I'll bet if you did have the ability to find and repair (or zap) a defective page, you would have been able to use it in the past to save enormous amounts of effort... restoring a large database is never easy. Try this search: how do i fix a bad "sql server" page? Now try this: how do i fix a bad "sql anywhere" page? Sadly, this is one area where The Watcom Rule has never applied to SQL Anywhere.
(17 Sep '18, 15:40)
Breck Carter
Not sure. I guess I would have still gone the official way by restoring from my backups, probably by also trying to include uncommitted operations from the current log by translating it to SQL statements... Of course it there were a REPAIR CORRUPT PAGE x statement, I'd certainly consider that, as well.
(18 Sep '18, 03:36)
Volker Barth
|
|
Actually I am in search of any solution that allows me to recover some data that are of immense importance to me, I am willing to try any procedure. Anything is open to new ideas. thank you Just a further hint. You are using 16.0.0.2043, which is an old v16 build, so you may give a fresh build a try, on Windows the most recent one is 16.0.0.2704. - Note, that may or may not help to restore the database but it's probably a much easier attempt than to try to repair database pages by yourself...
(20 Sep '18, 03:27)
Volker Barth
Long time ago... one interesting man showed everyone this tool. It doesn't use ODBC to access the DB, however it reads data from DB file directly. You can try its trial version. Maybe it is what you need.
(20 Sep '18, 03:27)
Vlad
1
...and there's no backup, right?
(20 Sep '18, 03:28)
Volker Barth
|
|
I will try all the solutions presented here. thank you very much. |