Hello, I'm using llblgen pro 2.5 (28 August) and firebird 2.01.

Here's an sql field declaration: QTY Decimal(15,4) DEFAULT 0 NOT NULL,

I wonder why the corresponding llblgen generated field has a precision of 8, a length of 8, and a scale of 4? Is it a bug or could someone explain me?

Thanks in advance...

Are you generating for .NET 2.0? i.e. using the .2.0 version of the DQE?

Thanks for answering, Yes I'm using .net framework 2 and the lastest DQE.

The values in the table field in the llblgen pro project are the ones reported by the Firebird ADO.NET provider.

If you do a little test with the ado.net provider and use this code: DataTable columns = openConnection.GetSchema("Columns", new string[] { null, null, tableName });

the columns datatable will have all column definitions for the table specified. This should show the values you're seeing. Is this correct? If so, there's a bug somewhere, either in firebird or in the ado.net provider.

GetSchema() returns wrong information... What should I do?

I guess you can report this bug to microsoft and firebird as well. In the mean time, you can do a simple hack, try to manually change the generated type definition in the generated code.

I have seen Carlos Guzmán Álvarez posting somewhere on this forum, I think I should contact him about that but there isn't any contact information in his profile...

carlosga AT telefonica DOT net

to contact him. Or file a bug report in the sourceforge project

I've had a look to the firebird bug tracker, it looks like it's a known problem which has already been fixed...

http://tracker.firebirdsql.org/browse/DNET-90

But only in v2.1 RC2 which isn't a final version yet...

stefcl wrote:

I've had a look to the firebird bug tracker, it looks like it's a known problem which has already been fixed...

http://tracker.firebirdsql.org/browse/DNET-90

But only in v2.1 RC2 which isn't a final version yet...

You could opt for that in the meantime... other than that, it's something they have to release as a fix, so if the RC is the one which has the fix, you could opt for using that one in the meantime. But it's of course your call...

This bug has supposedly been fixed in the Firebird Client for .net version 2.1 but, unless I am mistaken, LLBLGen is built against the version 2.0 client. Am I missing something, or is there likely to be a LLBLGen version that will work with the 2.1 client in the near future (or better still, there already is, but I missed it)

You may use an "assembly redirect" in the config file to let LLBLGen use the new version. Or better you may rebuild the firebirdDQE against the new version, just remove the old one from thr references and add the new one instead.

The firebird v2.1 connector doesn't install a policy file. The maintainer of this connector is very stubborn and refuses to add one. So a manual assembly redirect is the only option. If we compile our code against v2.1, all v2.0 using customers have to upgrade their software as well, which is not what we want.

Many thanks for the quick and positive response. I should have thought of that, but I can be remarkably stupid sometimes. For future reference the 2.1 connector does solve the problem with decimals, but it seems to mess up the reading of the IsNullable state of columns, ie IsNullable is always false