One thing jumps out here:
The entire process uses the same set of login credentials
Problem
So hypothetical userX (whether some meatsack using Excel, or IIS AppPool Identity) can see some views and code. It doesn't matter what database these views and code are in because userX is setup in 3 databases anyway.
However, you lose ownership chaining like this.
Let's say WebDB.dbo.SomeProc
calls PrivateDB.dbo.SomeTable
. UserX requires permissions on both objects. If this was OneDB.WebGUI.SomeProc
using OneDB.dbo.SomeTable
then only the OneDB.WebGUI.SomeProc
needs permissions. Permissions on referenced objects with the same owner are not checked.
Note: I haven't looked too deeply at cross database ownership chaining. I only know plain old "ownership chaining" well
Now, as per comments you really have 2 databases that can be combined. Not 3 which was originally implied. However, the intermediate and web can be combined.
The other "private" databases can perhaps be combined, but that'll be a separate issue. See the bottom link for a fuller discussion of "one database or many"
Solution?
If the extra databases are code containers only, then schemas are a better idea.
This sounds like you've used "Database" where you should use "Schema" (in the SQL Server sense, not MySQL sense). I'd have a WebGUI schema, a Helper or Common schema (to replace Intermediate database) and Desktop schema. This way you separate permissions based on clients and just have one database
With one database (in addition to "ownership chaining") you can also start to consider indexed views, SCHEMABINDING (I use it always) and such that can't be done with seperate databases
For more on schemas, see these questions:
Finally, there appears no reason to have separate databases based on "transactional integrity not required". See this question to explain this:
Decision criteria on when to use a non-dbo schema vs a new Database
For a failover-type situation, I use the handy 'sp_help_revlogin' stored procedure as published in http://support.microsoft.com/kb/918992
This procedure, when run on your primary server, will script out each login WITH the SID (this is the important part for making sure your logins are mapped to their respective database users) and hashed password (so the password remains the same on each server.) The resulting script can then be run against your failover server to create the logins. Be sure to review the output before running it.
As-is, it scripts all of the logins in the server, but could be modified to script only the logins you're interested in. It could also be automated to generate a script on a regular basis.
Best Answer
There are three ways to find who is connected to a database in sqlserver.
First one:
Use the SQL SERVER Management Studio -- Management -- Activity Monitor This gives a list of users, database names, status, command, transactions, application with which they are using the database, CPU, IO and Memory usage, Login time etc.
Second One:
Use the built in stored procedure called sp_who2 Run the command exec sp_who2 This gives a list of users, database names, status, command, program with which they are using the database, CPU time, Login time etc. Third One:
Third one Use the script
From the above methods, you can use them to implement in a sql job to get required notification.
The best method i used is the latest sp_whoisactive by MVP Adam Machanic