I don't know how crazy this is going to sound, but here goes:

Create one database, with one set of tables. In each table, put two additional columns, one for user and one for DatabaseID (I can't remember what the different databases stood for, so I'll use DatabaseID as the column name).

Add another table, so that each user has a list of DatabaseID's associated with their usernames (windows authenticated user names, USER in t-sql). Upon entering the program, they choose what DatabaseID to use (from the list that is associated with them), and assign that to @dbidtouse, for example, for use below.

Use row-level security with views to restrict their access to the data in the table and in the program, put an extra where clause on the select statement to get the data pertaining to only the DatabaseID they are interested in at the time.

SELECT * FROM vSomeTable WHERE DatabaseID=@dbidtouse

Grant select on the view to all users, but in the view:

CREATE VIEW vSomeTable

AS

SELECT * FROM vSomeTable WHERE tableUserName = USER

This would make it where they could never see any data other than their own, even with a select statement that is openended. (Don't give access to the underlying table, just the view.)

As stated above, the program would further restrict the results by putting the "WHERE DatabaseID=@dbidtouse" clause on the view's select statement to narrow it down to just the DatabaseID they are interested in.

As they want to delete DatabaseID, just delete rows in the underlying tables with user=USER and DatabaseID=databaseToDelete.

Oracle has the same thing as USER, can't remember what it is.

I think that would work in Oracle or SQL Server. Would that solve the problems?