DB recovery using -a

[MCMartin]

I have had the situation in 12.0.1.4155, where I wanted to apply the latest logs to a backup of a database. So I used dbeng with -a "transaction.log". I was very confused, when a message dialog appeared telling me that the access to this file was denied. The file was readable and renameable, so no access denied from Windows...

Using this file through the dbtran tool was no problem at all. So was applying the SQL commands extracted by dbtran.

So what is "access denied" really refering to when using -a?

[VolkerBarth]

Could it be the file was opened by another process? (Though then renaming would certainly be not possible...) Or may this be an UAC side-effect?

(Very wild guesses, I agree...:)

[Former Member]

dbeng may be having more of an issue with the main database (or maybe a missing dbspace?) can you show the exact dbeng12 cmdline and text of the error?

[justin_willey]

Is the database expecting its log file to be in a specific location, rather than just in the same folder. Where is the log file on the production database server, in the same folder as the db file or elsewhere?

[MCMartin]

command line was dbeng "databasefile name" -a "transaction log file name" nothing else. Unfortunately I haven't made a screenshot of the dialog. From my memory the message was "access to transaction log file (filename) is denied". Running the database without the -a was no problem, so I would guess no problem with the main database (it has only 1 dbspace).

[MCMartin]

-a is providing a transaction log at a specific location and in my case it was not the same as the productive database transaction log

[Former Member]

The most likely error you could have seen would be this one

"Unable to open database file "<path-prefix>\\<filename>.log" -- Permission denied"

and the most likely reason to see that is if that file is opened for r/w use by another program. For very common example for this error to occur try translating a log that belongs to a database that is already open on a running server.

Either way the failure would seem to be external to the SQL Anywhere utilities (unless the file is already in use by one of them).

I would try copying it to another file name and see if you can dbtran that copy.

[Former Member]

Incidentally, if the log is attached to a running database, then you can translate that by connecting to it (by using the dbtran -c switch)