Running Sql Anywhere 9.0.2 on a standard 2008 windows server
running in a virtual machine.

Condition:
C++ application
Copy 20mb database to server over a network connection.
Immediately call start database SQL Command via ODBC.
Fails with: Specified database file already in use

Solutions Attempted:
I tried sleeping between the copy and the issuing of the
open database command.
Sleep 1 sec after copy -> FAIL;
Sleep 5 sec after copy -> FAIL;
Sleep 20 sec after copy -> SUCCESS;

Determining that there is some delay before proper access to
the file is achieved I built a loop calling CreateFile
asking for exclusive access. I would loop every sec for
thirty seconds until the file was opened successfully. I
would then close the file and submit the start database SQL
command.

In execution the first attempt to open the file succeeded
and the subsequent Start database command succeeded.

This suggests that some “flushing” of the OS cache is
occurring on the create file command, which does not occur
when Sybase attempts to open the database.

Thoughts?

Kyle

This is probably just tied up while the local virus scanner
checks it out. Disabling that for .log and .db or all files
in the directories dedicated for use with database/data
files should correct for that.

As for the server, we require the ability to have exclusive
control over this file. And it's directory entry too [we
will mark the directory entry as r/o]. Depending upon
your CreateFile you may be asking for shared or r/o
access which may succeed even when the server
would not. But that is neither here or there if my
first point carries the solution.

<Kyle Danielson> wrote

Running Sql Anywhere 9.0.2 on a standard 2008 windows server
running in a virtual machine.

Condition:
C++ application
Copy 20mb database to server over a network connection.
Immediately call start database SQL Command via ODBC
Fails with: Specified database file already in use

Solutions Attempted:
I tried sleeping between the copy and the issuing of the
open database command.
Sleep 1 sec after copy -> FAIL;
Sleep 5 sec after copy -> FAIL;
Sleep 20 sec after copy -> SUCCESS;

Determining that there is some delay before proper access to
the file is achieved I built a loop calling CreateFile
asking for exclusive access. I would loop every sec for
thirty seconds until the file was opened successfully. I
would then close the file and submit the start database SQL
command.

In execution the first attempt to open the file succeeded
and the subsequent Start database command succeeded.

This suggests that some "flushing" of the OS cache is
occurring on the create file command, which does not occur
when Sybase attempts to open the database.

Thoughts?

Kyle