Hi. I know there have been a couple other older threads about this, but I figured I'd start another regarding using LLBL Pro to create a web application that supports multiple databases for deployment.

I'm currently creating a commercial web application that I would like my customers to have the option of choosing which databse they would like to deploy it to (MySQL, SQL Server, and Oracle). Being a long time user of the old llbl for some quick and dirty hack projects, I decided to try out the professional version and really like it so far. What got me really excited was the prospect of using it almost exclusively for a persistance layer with the intent of being able to easily swap between different database providers (at compile time) without having to change any of my webproject's code. I'll also have another separate data access assembly that I'll swap out for each DB provider in case I need any custom queries with the interface being the same for each.

I read a couple places on these boards that the Adapter version was better for multi-db support, though I'm curious about why that is. I'm thinking of just sticking with the Self Servicing since its a bit simpler and easier to code against. My application doesnt need to be DB interchangable at runtime, as long as the referenced code project has the same classes and methods, I should be ok. I dont mind offering different binaries of my web app for each DB provider (ex: "MySQL version" vs "SQL Server 2000 version") as long as the only change that has to be made is which Generated Data Access DLLs the project references.

Anyone have any experience with this? What are some of the "gotchas" in terms of which classes and methods to avoid using to stay database neutral?

Thanks

-Jacques jc@comicjunkie.com

Well one advantage that you would lose is the ability to only have to write custom code in you DAL once. You would have to keep all 3 synchronized and then you would have to either create 3 web projects that use the different references or everytime you finished a build you would have to change the for the same product three times. I haven't used them in a multi-db type scenario yet to be able to give you a heads up with Self-Servicing.

selfservicing isn't multi-db because hte persistence info is in the entity. This means that if you have a CustomerEntity generated for sqlserver, you can't use it on oracle. though in adapter, you can. This means that you have with adapter, an application with entities and you can have multiple dbspecific projects, one for each database supported. You can then switch per call which db you want to access.