A couple of people have reported this message appeared. I have not been able to document the steps leadings up to it. But what does it mean? It has appeared, I was told, during or right after opening a database. I will supply more info if I can pin it down better.
This statement is new in b7, it allows code to pause and wait for the server to complete a task. It is currently used in two places:
- The connecttoserver statement. Sounds like that is not the problem here, unless you have code that is manually using this statement.
- When synchronizing, it is used when downloading data from the server.
In either case, it is only used it the operation was triggered from a procedure (not from a menu or from double clicking on a database). Note that if a database is opened as an auxiliary database, that counts as “triggered from a procedure”.
So, this problem can only occur if:
- The database is opened by a procedure, and
- The database needs synchronization
Looking at the code I don’t see how this error occurs, but I do see some possible problems with this code flow. So I’m working on trying to duplicate this problem.
Oh – the error means that it thinks it is already waiting for this task, and it can’t waiting for the same task twice.
After some further investigation, the “possible problems with code flow” turned out to be not a problem. Everything looks fine in the code, I figured out the flow was set up correctly. I also set up the scenario where I thought the problem might occur, and everything worked as it should. So, I have no clue.
This link will configure the instrumentation to log what is going on as databases are opened on the client. This should put information in the log that might help pin down the problem. I hope it’s possible for you to be able to grab a log from a client machine when an error occurs. You’re probably not that on-call. Of course it will be possible to grab it later, the only problem will be identifying where the problem is in the log. Perhaps ask the users to note the time if they see the error, then that can be matched up in the log later.