We are evaluating LLBLGen and were almost convinced it was the tool we should use until we found this thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=14176

As we have a commercial product (webservices and ASP.NET) which is installed on-site that supports Oracle (9 & 10) and MSSQL (2000 & 2005) we cannot have some limitation in choosing the databases we support. From the thread I gather that would pose a problem with LLBLGen (or at least cause many headaches and or additonal hand-coding).

I'm not talking about using Oracle or MSSQL specific features but general CRUD functionality. Is this true or did I jump to a false conclusion?

regards, Martin

I think the thread you refer to was really only commenting on the overhead of maintaining schemas for 3 or 4 seperate databases. As long as you do keep the schemas in sync, the overhead of using LLBLGen is minimal, and the coding should be transparent.

What you do is generate a DBSpecific project per database (Oracle 8,9,SQL etc) and just use one of the generated DBGeneric projects with all of your DBSpecific projects.

As that thread states, creating a DataAccessAdapter factory which hands you the correct version based on some configuration value somewhere leads to the client code being identical.

using (IDataAccessAdapter da = DAAFactory.GetDataAccessAdapter)
            {
                da.Fetch...
            }

MTrinder wrote:

What you do is generate a DBSpecific project per database (Oracle 8,9,SQL etc) and just use one of the generated DBGeneric projects with all of your DBSpecific projects.

Ok, we did try this but failed. When reading the MS SQL tables LLBLGen Pro generates all kinds of datatypes like System.Int, System.Int32 and System.Decimal. For Oracle only System.Decimal is generated for every kind of number (number, number(10,0) etc.) I could think off. Float is generated correctly as far as I can determine.

This means not only the database specific code is different but also the datatype of the attirbutes etc. Which means that the generic code is also different.

So either I'm missing something or there is more involved than only a xcopy off the database specific code?

MTrinder wrote:

As that thread states, creating a DataAccessAdapter factory which hands you the correct version based on some configuration value somewhere leads to the client code being identical.

Ok, is there any sample that shows some more code as this message?

regards, Martin

oops

regards, Martin

brekhof wrote:

MTrinder wrote:

What you do is generate a DBSpecific project per database (Oracle 8,9,SQL etc) and just use one of the generated DBGeneric projects with all of your DBSpecific projects.

Ok, we did try this but failed. When reading the MS SQL tables LLBLGen Pro generates all kinds of datatypes like System.Int, System.Int32 and System.Decimal. For Oracle only System.Decimal is generated for every kind of number (number, number(10,0) etc.) I could think off. Float is generated correctly as far as I can determine.

That's because Microsoft's Oracle provider is doing that: it returns all NUMBER(x,y) typed values as decimals.

Use ODP.NET to get proper typed fields.

This means not only the database specific code is different but also the datatype of the attirbutes etc. Which means that the generic code is also different.

Types can be made compatible through type converters. For example, if you use bitfields in sqlserver, you can create boolean entity fields in oracle too by using a NUMBER(1,0) field for example and use the shipped type converter (which is shipped as an example in sourcecode in the SDK as well).

In the customer area we also offer a project converter in sourcecode, which allows you to convert a sqlserver .lgp file to an ODP.NET using .lgp file complete with oracle meta-data. You then can generate DDL SQL from it using a template and use that to create the initial oracle schema for example.

Be aware that using a single application on multiple different database types is often more work than you might think: it's not as if you can simply switch connection strings and it works. For example, Oracle inserts "" for null in varchar fields, is case sensitive by default, uses sequences instead of identity fields, has no guid type, allows non-blocking transactions etc. These details can come into play at runtime with your application.