I have now have a selfserving Data access layer code generated for Oracle. I want to support the same schema in Sql server in the future. Whether it is possible to re-use the existing DAL for sql server also? I saw several threads suggesting to use adapetr model. But all of them are more than 3 years old. So I want to know in the recent version is there way to support both the databases (oracle and Sql server).

I have a Business Logic layer which is based on the current DAL, if i needs to access SQL server later whether I need to change the BL code? I didn't see any samples regading this. links to sample will be helpful/could you please provide a simple project demonstrating this?

Which version of LLBLGen Pro are you using?

I am using 3.1

For v.3.x, in the same LLBLGen Pro project, you can more than one Relational Model Data Storage. And you can map entities to tables from each Storage. (From the "Field Mappings" tab). When you generate code using the Adapter tmeplate set you'll get 1 dbgeneric project (with your entities) and 2 dbspecific projects.

For v.3.x, in the same LLBLGen Pro project, you can more than one Relational Model Data Storage.

Is the above means, I can add say "Employee" database (schema) from Oracle and the same kind of schema with the same name "Employee" from SQL Server into a single LLBLGen Project and generate a single Data access code for both the database (for both Oracle and Sql Server)?

How can I differentiate the connection to these database in config files?

At Project->Properties there is a key called ConnectionStringKeyNamePattern. The default value is Main.ConnectionString.{$ProviderName} which means that if you have two data stores (SQLServer and Oracle), two connection string keys will be generated:

...
<add key="Main.ConnectionString.SQL Server (SqlClient)" value="...
<add key="Main.ConnectionString.Oracle (ODP.NET)" value="...

Saravana, if this feature (which is present since 3.0) isn't clearly documented in the docs, or you found it confusing, please let us know how we can improve the designer docs to highlight this feature better. Our thoughts were that this was straight forward, but I think it needs more attention.

I also think that in 3.0 it was a new feature so it was highlighted as such, but as it's not something that needs attention through docs, it's not something that's been given its separate page in the docs. With v3.1, it's not a 'new' feature anymore and dropped off the list.

We'll make sure this feature gets more attention in the v3.5 docs.