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: http://dcx.sap.com/index.html#sa160/en/dbadmin/connect-session-terminal.html

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.