Database independence

Posts   
 
    
RobR
User
Posts: 2
Joined: 07-Jan-2009
# Posted on: 07-Jan-2009 15:32:20   

We have a requirement that our code work with different types of databases, including possibly some that haven't yet been invented. The actual database will not be known until run time, when a user will be presented with a listbox of names, and a connection string will be selected based on the user's choice. Our preferred database is PostgreSQL, but we need to support SQL Server, Oracle, DB2, and anything else our customers may require, all without changing our code. ODBC allows us to do this because the database is actually described in a DSN, and all the connection string has to do is to specify which DSN to look at. OLE DB could allow us to do it because the actual provider can be specified in the connection string.

Can LLBLGen work with this requirement? I noticed that if I select SelfServicing when I generate code, I can then use a method in DbUtils to select a connection string at run time. But can the generated code work with a PostgreSQL database one time, and then the next time work with a SQL Server database merely because the connection string changed?

Thank you very much.

RobR

Seth avatar
Seth
User
Posts: 204
Joined: 25-Mar-2006
# Posted on: 07-Jan-2009 16:47:03   

I know I have gotten it to work with the adapter model. See this. There are some obvious things that could be done to improve it, but in essence, it is the DataAccessAdapter object that comes from the provider specific dll's. This is created at run-time statically based on the dll provided using reflection. I've used it to target both MS Access and SQL Server without changing anything with the exception of the path to the provider specific dll. I don't think what you want will work with self-servicing.

Walaa avatar
Walaa
Support Team
Posts: 14993
Joined: 21-Aug-2005
# Posted on: 07-Jan-2009 17:17:40   

You should definitly use the Adapter model, and check the link Seth posted.

RobR
User
Posts: 2
Joined: 07-Jan-2009
# Posted on: 07-Jan-2009 17:23:29   

Seth,

Thanks for your reply. Your solution may be more than I'm going to need. A given customer will never have more than one type of database. In any case, I'm going to have to have a separate LLBLGen project for each available database type. That's what I was hoping to be able to avoid, but that's not really too big a deal.

I'm only just starting to look at LLBLGen, and I'm also quite new to C#. It's rather a daunting combination.

RobR