Access to multiple database confusion!

I have reviewed the posts on this and to be truthful they don't provide sufficient clarity. Here are my assumptions:

1.  I have two separate databases(different schemas): db1 and db2.
2.  I have built a separte NetTiers data layer for each.
3.  From within my application I wish to perform CRUD operations into either database at runtime.

 This post (http://community.codesmithtools.com/forums/p/3108/12847.aspx#12847) describes how to set up my web.config file for both databases.

 Then this post (http://community.codesmithtools.com/forums/p/2932/12166.aspx#12166) tells me all I have to do is change the connect string, which to be truthful does not make much sense to me unless both databases have exactly the same schema.

Intuitively I need to create web.config references for each database in ConfigSections, ConnectionStrings, and in the netTiersService sections. I think my confusion is how to set up the netTiersService section.

If this section's default provider references db1, how do I create the reference for db2? 

Just as importantly, how do I programmatically choose to reference the db2 provider within my app?

Thanks,

 Rich Solutions

The first link you gave is what you want to do. The second link on changing connection strings is if you have two databases with the same schema and you want to programatically switch the NetTiers connection string.

 If you do what the first thread suggests (http://community.codesmithtools.com/forums/p/3108/12847.aspx#12847), then you have two NetTier's namespaces wired up (TSC and SFMembership). You just use each NetTier's namespace like you always did, and the providers will sort themselves out. For example, you should be able to do:

SFMembership.Services.UsersService UserService = new SFMembership.Services.UsersService();
SFMembership.Entities.TList<SFMembership.Entities.Users> AllUsers = UserService.GetAll();

TSC.Services.OrdersService OService = new TSC.Services.OService();
TSC.Entities.TList<TSC.Entities.Orders> AllOrders = OService.GetAll();

Doni

I use two different netTiers solutions all the time (one for the application and one for my custom authentication providers).  If you look in DataRepository.cs (in your Data project) at the NetTiersSection property, you will see that it looks for two different section names: netTiersService and <YourDataNamespace>.  As a matter of practice, I never name my sections as netTiersService and always name them according to my data access layer namespace.  This makes it very clear what netTiers libraries are being referenced by each section. 

Thanks Ben. This solved my problem.

So the accepted solution is to generate two separate solutions, one for each database?  Would you need to make sure each was in a different namespace to avoid the conflict on common classes like DataRepository?

 Is there a way to map to two databases with only one copy of the non-mapping specific files?

 Finally (and I apologize for being off topic) Is there a way to have the final entities in different namespaces instead of all being lumped together (and preferably not broken apart by which database they originated from?  Example: Test.Data.Customer and Test.Data.Products each with several related entity classes.

 We are in the process of moving from Sybase to SQL Server, and cannot do it all at once, so we want to be able to slowly migrate tables and related portions of code over the next 1-2 years. 

 So the accepted solution is to generate two separate solutions, one for each database?  Would you need to make sure each was in a different namespace to avoid the conflict on common classes like DataRepository?

Yes, you would generate one solution for each database and you will need to give them different namespaces.

 Is there a way to map to two databases with only one copy of the non-mapping specific files?

 Not that I know if.  There have been some discussions about breaking out the common netTiers classes into a separate library, but we haven't actually done anything in this direction.

 Is there a way to have the final entities in different namespaces instead of all being lumped together (and preferably not broken apart by which database they originated from?  Example: Test.Data.Customer and Test.Data.Products each with several related entity classes.

No, the entities all live in a single namespace. 

Has anyone on the forums implemented something similar that might have some advice on this?  Since our long term goal is to move the entities to the new db, I'd live to avoid having to change all my references to the new namespace/solution each time an entity gets moved.  We have a very small team though, so the extra complexity of having a facade and keeping track programmatically of which entities are instantiated from each repository might be overkill.