Sorry if dupe, I can't find the question I posted yesterday.

To meet DOD requirements, we need to run our application as a standard user but run the backup script as a scheduled task as the SYSTEM user. We are getting sybase error 9 - DB already in use. Appears the issue is no problem if all connections are by the same user (oh, we using Integrated Login under Windows 7 using dbeng16).

asked 26 Jun '15, 12:08

vorear's gravatar image

accept rate: 0%

Apparently you have opened up a support incident on this same question but have not provided some of these details there. Have you considered running the BACKUP DATABASE statement instead of running an external script? It is quite possibly failing because of your integrated login is failing because dbbackup is not running as a domain user.

(26 Jun '15, 12:16) Nick Elson S...

To complete that thought, you would use a database event to schedule the backup instead of the Windows scheduler.

(26 Jun '15, 12:24) Nick Elson S...

Actually we restored the backup as an event.

(01 Jul '15, 12:27) vorear

For clarity, I assume you are talking about OS scheduled events rather than database scheduled events. In that case, I think you are likely bumping into Windows session isolation issues.

The error you are reporting indicates that a second server is being started and attempting to open a database file that is already in use by another server. You need to have both of your apps connect to the same server. A scheduled task running as the SYSTEM user will not have access to the shared memory port of the database server running on a user's desktop. This part of the doc may help:

Probably what you want to do is start up the database as a Windows service as a standard user. Your app, whether it is running as a service or on the desktop, will be able to communicate with the database server running as a service. I'm assuming scheduled events runs in session 0 (same session as services) so they should then be able to communicate with the database server too.

Both your app and backup should probably remove the database filename component from the connection strings and rely on a server that is already running (as a Windows service). You don't want to autostart a database on a desktop or in session 0 based on which client autostarted it. Since this is a DoD installation, you want to be especially careful about this. In your current configuration where it appears that both your app & backup event can autostart the server, your backup event would probably work if the app (and database server) were not running. In that case, your backup event would autostart a server and that server would then run as the SYSTEM user. Your app which runs as a standard user would probably be able to connect to the server that is running as SYSTEM (as described in the link above, desktop sessions can reach into services but not the other way). It's possible that your security requirements are such that the database server itself should never run as the SYSTEM user.

permanent link

answered 26 Jun '15, 14:07

John%20Smirnios's gravatar image

John Smirnios
accept rate: 40%


Excellent answer, kudos from me and my team. That was the problem and we've found a solution. Sorry for the delay, I wanted to wait until the solution was proven.

(01 Jul '15, 12:25) vorear
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: 26 Jun '15, 12:08

question was seen: 375 times

last updated: 01 Jul '15, 12:27