If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Just because MS has a writepage, does not mean that Sybase will have one, there is no such thing, no back door.

To read a page, the simpler syntax is:

Code:

dbcc page ( {dbname | dbid}, <page_no>)

1 If your page is not damaged (by disk failure):
Sybase does not allow "pages" or "bytes" to be written to the database. The correct method, is to go through the front door, INSERT, UPDATE, or DELETE; which will ensure that what you "write" complies with all security, RI and constraints in the server/database. There is no use having those structures and rules in place, and then allowing people to come in through the back door and write a few bytes here and there; it would then no longer be ANSI SQL compliant, secure or correct (with reference to rules and constraints).

Of course, there is back door in Sybase. Sybedit utility can do this job, but it seems that it"s no more part of ASE distribution. Sybedit looks, in fact, as a wrapper for dbcc commands, so I guess there might be dbcc for direct insert into pages.

1 Sybedit was an abortion, that was quickly removed from distribution, many years ago, before ASE 12.0. There was a back door only by accident (not by conscious choice or design) for a very short time, and that was quickly closed ... there is no back door now.
2 Whitesands needs to learn SQL, and use the front door. Every other front end (reporting tools to DBA tools to developer tools) do not have this "problem", just Whitesands ... but they somehow try to make it someone else's problem !!! Instead of changing DBMSs to fit Whitesands "model", it would be more reasonable to change Whitesands to fit the ANSI SQL model. Check out the other great DBA tools that have no such um "problems".
3 If dbcc cannot fix it with the "fix" option, there is no chance a developer can fix it by fiddling with the bytes. The internal structures for data and index pages are not published.
4 Sure, you do get hard errors when a disk fails. If you do not have disk mirroring, then you need backups, that is what the backups are for.

I'm just trying to say that there are methods how to update pages directly (fixing pointers etc.) though they're not officially supported. Most of the dbcc commands are not supported too or at least are not mentioned in the manuals but they are sometimes very usefull - dbcc prtipage for example. Of course, I agree that tools for updating pages directly should be used only on own risk and as a last resort.

I wanted to put the final resolution in the thread for anyone else running across this problem. In response to Derek, there is dbcc dbrepair(dbid, writepage, pageno ... , however the syntax isn't perfectly clear and its a pain. You don't always have backups nor do you always control your client's systems and sometimes have to work in ways you may not prefer.

luzi, thanks for the reply and I'll take a look.

Here is what I finally did:

In ISQL

1>dbcc traceon(3604)
2>go

1>dbcc page(dbid, page, 2)
2>go

This will yield a copy of the database page with a hex dump of the page contents. Looking at the header and the first two lines of the hex dump will show you what to look for in the header if you need to open the database in a hex editor.
PAGE HEADER:
Page header for page 0x2F009000
pageno=1791072 nextpg=1805145 prevpg=3862817 objid=1086626914 timestamp=0001 32c85f60
nextrno=67 level=0 indid=0 freeoff=1628 minlen=4
page status bits: 0x11 (0x0010 (PG_RNOFREE), 0x0001 (PG_DATA))

Using windows calc in scientific mode, pageno=1791072 translates to 1B5460. Commonly when looking at a hex dump the byte order is reversed. Broken into bytes, this number is 1B 54 60. Reversed it is 60 54 1B. Since it’s shown in groups of 4 bytes, this maps to the first word of data: 60541b00. It follows then that the rest of the header is shown pretty much in order. 598b1b00 is the hex nextpg value and 21f13a00 is prevpg. Objid is 629cc440.

To directly edit the header I had to open the .dat file in a hex editor. I used HxD, a free download. Most should function in the same way. HxD has the advantage of opening very large files. Taking the first 4 words of data and putting them together with no spaces gets us: 60541b00598b1b0021f13a00629cc440. I stopped Sybase and opened the .dat file with HxD. Clicking on Search and then choosing hex values and search direction all, I search on the number we have. This is the row I found: 60 54 1B 00 59 8B 1B 00 21 F1 3A 00 62 9C C4 40. Hex editors will show an offset to the left that is the reference for row you’re on. Jot this down to make finding the start of the page easier.

Now, for my problem I needed to skip a page. This meant I needed to edit the next page pointer on the last good page in the chain and the previous page pointer on the next good page. Repeat the above for the pages involved (previous, the one you're skipping and the next page). Once you know these values you can translate them to hex, reverse the bytes and write them into the .dat file. For other errors you may be able to simply edit the objid to repair it. This will not fix corruption in the data itself and sometimes will only show you more corruption past the page you fix.

I would recommend you use dbcc pglinkage to follow the chain of pages in the table to at least ensure you are only trying to fix one bad page. Obviously this entire exercise assumes that you have no good backups as the best policy is simply to restore to a point before your error happens as Derek points out.