Hi

After some tests and consulting the source of the SDK of LLBLGen I found a Bug (I think it is ab bug):

I use the following Tools/Versions:

• LLBLGen Pro: 1.0.2005.1 Final
• ODP.NET: 10.2.0.1.0
• Oracle DB 10gR2: 10.2.0.1.0
• VS2005: 8.0.50727.42
• .NET-Framework: 2.0.50727

Now the bug: I defined a column in oracle as FLOAT and read the schema with LLBLGen. If I define the FLOAT in Oracle with precision of 16 or greater it is mapped to a System.Decimal. This produces casting exceptions in .NET-Code because internally it uses a double and in the Entity in the property-getter it casts it (wrapped in an object!) to a decimal.

If I define a precission of less the 16 it mappes it on a Int64/Int32 which is'nt correct. The error is in the method OracleDBDriver.DBType2NETType() where the scale is used to check if it is a Integer or any other numeric type.

If i define a FLOAT in oracle scale is NULL (empty!) and this results in scale==0 in the method OracleDBDriver.DBType2NETType() !

please check the Mapping.

My english is'nt so good but I hope you can reproduce this issue.

If you need more informations, let me know it.

The mappings in the oracle 10g driver are based on ODP.NET's 10.1.x.y mappings.

Ok I see your point. The routine indeed shouldn't be ran when the type is a FLOAT, only when it's a NUMBER.

To work around it, define your type as a NUMBER(x,y) till this is fixed in the driver.

All values are stored in a type object, because there's just one parameter for the value, Currentvalue, and that has to contain all possible types, hence object.

(edit): Ok, had some serious trouble with my SqlTools application to reach my oracle box, but now I have it working again, so I could run a test! . I reproduced the problem: a FLOAT typed field indeed resolved to a DECIMAL, which is of course wrong.

I'll fix this in the driver. If you need it TODAY, you can simply change the line in DBType2NETType() where it tests for FLOAT at the top of that routine into a check for solely number types, which should result in DOUBLE typed fields after a refresh of the catalog. (so after the driver has been updated, the refresh has to be done.). I hope to have this fixed by mid-day.

I use now your work around.

But: I would like to use Double in .NET-Code not decimal.

When are the new ODP.NET features implemented in LLBLGen Pro, how is it planned?

For the project where we use LLBLGen it is importent to use FLOAT and also the correctly implemented types in .NET.

roland wrote:

I use now your work around.

But: I would like to use Double in .NET-Code not decimal. When are the new ODP.NET features implemented in LLBLGen Pro, how is it planned?

Which new features are you referring to, you mean the ODP.NET v2 specific features? That's unclear. Oracle started the beta of their new ODP.NET version a week ago, though they don't expect to release before May. We hope to release v2 of llblgen pro before their odp.net release, though we can update our drivers/DQE at any time after that if required.

For the project where we use LLBLGen it is importent to use FLOAT and also the correctly implemented types in .NET.

I will have a fixed driver for you within a short time. Stay tuned.

Ok, big problem: ODP.NET v10.1.0.301 (and earlier) returns a FLOAT value as a Decimal. So I can't change it to a Double mapping because the value is returned as a decimal, hence the reason why it was mapped as a decimal.

I can solve this in the driver, but with some tricks. I think it depends on the ODP.NET version, not the DB version. I'll try to check the version, if it's 10.2.x.x or higher, FLOAT will be mapped to double, otherwise to decimal (it's in a table, so that's easy). I don't have 10.2 installed, so I'll mail you a test version when I'm done adding this code.

(edit) Ok, I think I fixed it. I'll now mail you a new build of the 10g driver. You should copy the driver into the drivers\Oracle10g folder and restart llblgen pro and refresh the catalog, after you've changed the type of the field back to FLOAT in the db of course. The FLOAT field now should be a double (check it in the entity editor). Regenerate code and it should work as expected. If not, please let me know.

(edit): I've send you an email with the fix. If you don't receive it, please let me know (or check hte spamfilters )

Your testcode works!

Thank you very much.

For me it is ok if you implement the current released ODP.NET Driver correctly in your next version of LLBLGen Pro so it mappes the types correctly how Oracle Mappes them in her Versions.

At the moment it works for me, let me know if you have a new version of LLBLGen which supports the actual ODP.NET implementation.

roland wrote:

Your testcode works!

Thank you very much.

For me it is ok if you implement the current released ODP.NET Driver correctly in your next version of LLBLGen Pro so it mappes the types correctly how Oracle Mappes them in her Versions.

At the moment it works for me, let me know if you have a new version of LLBLGen which supports the actual ODP.NET implementation.

It's build in the current version I did a simple trick: When the driver is created, I check the assembly version. If it's 10.1 or lower, I map to a decimal, otherwise I map to a double. As it's table based, I can just set some table values and it works as expected (i.e.: when the assembly version is 10.1 or lower, I replace the table values for Float to decimal based values ). So I can keep the current codebase and make it work on all odp.net 10g versions

Thanks for testing, I'll roll out the fix in the next build