Dean: We have the same issues you do when we start to host our app. However, my boss says that our clients will not share a DB. So what we have decided to do is have a public Web Serivce where all calls are made. When a user logs into the system, part of the user profile is to say what server and what DB he belongs to. Of course all users will have to be in a common/master DB on one server. Part of the user profile that we send back to the client is the server and DB names. When the client makes additional Web Service calls, the server and DB name will be passed. I don't know if this is the best approach, but it solves the issue of hosting apps to companies that want their data in a seperate DB.
-----Original Message----- From: Dean Cleaver [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: [DOTNET] Multi-tennanted apps. Having .config files for apps is great, however I have a client who is an ASP (using Citrix XP), and as such all servers have their own copy of the exe, and all users share the 1 exe (and thus 1 config file) per server, even though they are all from different companies, and would need different connection strings to the database. Has anyone done this type of development before, and does anyone have suggestions on how to deal with this on a "per company" basis (I'm assuming I can get the company name or identify the users company from the Active Directories somehow - maybe even from their email address or something)? One option was to get the .config to point to a database that has a list of connection strings per company for the real databases. Another option was to have the real database and prepend the company name to the tables, such that all companies share a common database, but have their own distinct table names... Any other thoughts/ideas? TIA Dino --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.363 / Virus Database: 201 - Release Date: 21/05/2002 You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
