Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.


When applying a log file to a standby database we get an assertion 100904 with the message: User 'another user' has the row in 'WPKView' locked

Clearly there is no other user as we only have the server up for applying the log - but what could be causing this? We have re-tried recopying the original database and reapplying the logs but have the same problem.

This is a process that has been running for several years without previous issues and nothing particular has changed and has been very reliable. Each week a full db copy is taken and moved to the standby server, then during the course of the week log backups are applied. At the same time a live backup is running, so that we could quickly bring the standby server right up-to-date in the event of a failure of the main server.

We now can't get past the log causing the problem - leaving us exposed. Does the problem also imply some sort of potential corruption of the main database?

I can see reports of this error in previous versions but no explanation of what causes it. Any suggestions appreciated.

From the console:

I. 07/24 08:23:52. Finished checkpoint of "pears" (pears.db) at Tue Jul 24 2012 08:23
E. 07/24 08:23:52. *** ERROR *** Assertion failed: 100904 (
E. 07/24 08:23:52. Failed to redo a database operation (id=4, page_no=0xd00008a0, offset=0xa4e) - Error: User 'another user' has the row in 'WPKView' locked
I. 07/24 08:23:52. *** ERROR *** Assertion failed: 100904 (
I. 07/24 08:23:52. Failed to redo a database operation (id=4, page_no=0xd00008a0, offset=0xa4e) - Error: User 'another user' has the row in 'WPKView' locked
I. 07/24 08:23:52. 
I. 07/24 08:28:52. Database server will shut down after startup completes

asked 24 Jul '12, 05:49

Justin%20Willey's gravatar image

Justin Willey
accept rate: 20%

edited 24 Jul '12, 06:28


This may be related to User 'another user' has the row in 'mytable' locked which refers to a fix that your build may or may not contain... and it refers to a situation (idle time) completely unlike yours.

FWIW is the most recent (and final?) EBF for 10.0.1 on Windows. The read me contains this one mention of your symptom...

    ================(Build #3535  - Engineering Case #476067)================

The CREATE INDEX statement was not respecting the setting of the Blocking 
    option, and would always have failed if another transaction had the table 
    locked (for shared or exclusive access). As of version 10.0, this is more 
    likely to be an issue as the cleaner locks tables temporarily as it does 
    its work. In particular, a reload could have failed with errors of the form 
    "User 'another user' has the table ... locked". This has now been 

Plunging onwards...

Please show us the following two command lines: the dbsrv10 command line that was in effect when the log files were originally created, and the dbsrv10 command line that was used to apply the logs via the -a, -ad or -ar options.

If the two command lines are significantly different (e.g., dbeng10 -a was used instead of dbsrv10), the roll forward process may not have the same resources available to apply the logs that the engine had when the transactions in the logs were originally processed; e.g., not enough threads, RAM, whatever. The roll forward process is pretty much a replay of what went on before, minus the wetware :)

(24 Jul '12, 07:30) Breck Carter
Replies hidden

Thanks Breck - there are two things there I can follow up on. First the live server is on build 4310 so we'll apply the same ebf to the standby, second although both command lines are using dbsrv there are significant differences in RAM etc so we can try altering that.

(24 Jul '12, 07:53) Justin Willey

...don't forget to wave a dead chicken over the keyboard, might not help but never hurts :)

(24 Jul '12, 10:16) Breck Carter

Unfortunately neither updating the version of the software on the standby machine or getting the memory & thread options in-line helps. It leaves us copying the later backup down and hoping it doesn't happen again- but at 150G zipped its going to take a while :(

(25 Jul '12, 11:11) Justin Willey

"Call tech support" is the next step... usually... but if it's a bug in V10 it ain't gonna get fixed... 11.0.1 is highly recommended, and you don't need to unload/reload the database.

(25 Jul '12, 14:25) Breck Carter

Justin, please contact technical support. I have an idea what is going on, and I think we should be able to come up with a workaround for you.

permanent link

answered 25 Jul '12, 16:51

Glenn%20Paulley's gravatar image

Glenn Paulley
accept rate: 43%

Thanks Glenn - I'll do that

(25 Jul '12, 17:51) Justin Willey
Replies hidden

It's opened as case #11747103 - thanks

(26 Jul '12, 07:54) Justin Willey
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 24 Jul '12, 05:49

question was seen: 6,240 times

last updated: 26 Jul '12, 07:54