on 2018 Sep 11 11:00 PM
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.
Request clarification before answering.
I will try all the solutions presented here. thank you very much.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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...
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.
I think, I am the only one, who mentions this tool from time to time, and I don't get anything (good and bad) for it 😞
to recover some data that are of immense importance to me
...and there's no backup, right?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
> 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.
I'll bet if you did have the ability...
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.
User | Count |
---|---|
75 | |
30 | |
9 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.