Hi,
that's something you should be able to do using the adapter scenario.
Have a look in the manual for full details, but basically, what it does is separating the data model from the persistence service into two .Net projects.
Once your structured generic queries are built, the **DataAccessAdapter **object is responsible for generating them in the corresponding sgbd thanks to the mappîng instructions exposed by the PersistenceInfoProvider.
You can do it by several ways:
have two LLBLGen projects with your two dbs, generate the 2+2 .Net projects, keep one of the generic projects, and the two dbspecific projects. Merge the orphan PersistenceInfoProvider so that it keeps in sync with the other one (correct the entity side of the mapping )
Alternatively, make a single LLBLGen project and use the project converter (recently released) to convert it to the other sgbd. regenerate, keep either generic code (the projects should be close to similar), and again merge the PersistenceInfoProvider (this time you have to adapt the sgbd side of the mapping to fit to your dbase)
In both cases, build all of your queries with an abstract DataAcessAdapterBase, which you provide at runtime according to your config, using a provider pattern.
Changing the namespaces depends on the way you implement your provider pattern. If you use reflection to load the right dll, then the namespaces might be the same. If you explicitely instantiate the concrete adapter in your code, then they need to have different namespaces. Overall it's probably safer to get different ones.
Cheers
