Many thanks for the prompt reply.
There are two reasons for me wanting to have a separate database for each client (although this may be naive of me):-
1. I guess I feel a bit safer keeping different clients data separate. If it were all in one database, and the database got corrupted, then all clients would be unable to login whilst the problem was fixed. Also, if we needed to restore to a backup, then I am guessing everyones data would be set back to the restored data (although with SQL Server I suspect there may be ways round this - that's probably another discussion!!)
2. Our different clients might want to login with the same user names, for example client A might have a user John Smith who wants his login user name to be JSmith, and client B may also have a John Smith who also wants his login user to be JSmith. From what I have seen so far, you can't have two different users with the same login, even if they have different e-mail addresses (although I may be wrong on this one?).
Hence why the different data databases and different security "LocalSqlServer" databases for different clients.
Like I say, it may be that I am approaching this in completely the wrong way, or it may be that I won't be able to use the built in Login controls to control security.
Having had more time to think about this, I don't think I can achieve what I want anyway, as the built in login controls rely on the "LocalSqlServer" connection string, and if I can't change this at runtime from what it is defaulted to in the web.config file, then there can only be one security database (ASPNETDB.mdf) that the web site can use.
If you have any further thoughts on this, i really do appreciate you taking the time and effort to help me, as I know you have your own stuff to get on with.
Thanks for the info you have given me, it's nice to find out how the professionals do these things.
It sounds like I am approaching this in the wrong way, and that I should just have one data database and one security database, in which case am I correct in thinking that all my data tables will have to have an "account" field to differentiate between different clients (sorry, I use the term client to denote one of my customers, as opposed to a workstation at the user end - apologies for confusing terminology!)?
Also, having just one security database; does mean that user names will have to be unique across all customers?
Once again, many thanks for your time!
quote:Originally posted by James Evans
Hi TwoTrees -
I am wondering - is there a reason that you need to have a separate db for each user? You can key all your tables by user id and have everything in one db. I work on a lot of large enterprise web applications and this is the usual technique.