Hi,

we encountered the following problem with Oracle: when we map a (nullable) column of the db type Timestamp with timezone, the LLBLGen designer maps this column to a DateTime? property. When I now access this property in the code, it works with the Oracle.ManagedDataAccess(.Core) driver in version 21 (3.12.x). However, when I use the newest 23 version (23.9.1) I get an exception Unable to cast object of type 'System.DateTimeOffset' to type 'System.Nullable'1[System.DateTime]'.

I tested a bit with the different driver versions and it turned out that Oracle seems to have done a breaking change here: when using data.Reader.GetValues(...) and let the driver decide the db=>.net type mapping, the v21 driver returns DateTimefor "Timestamp with timezone" and the v23 driver returns DateTimeOffset. LLBLGen however, expects DateTime, therefore the cast exception.

The interesting thing is that this change isn't documented anywhere or at least I couldn't find it. The only thing I could find is, that in the Oracle 19 .net developer guide, the mapping is still "Timestamp with timezone" => DateTime, in the Oracle 21 guide it's suddenly "Timestamp with timezone" => DateTimeOffset, but the driver still has the old behavior and in the newest guide it's still the new mapping but now the driver seems to also behave like documented. But no documentation of the change itself.

This is cleary not a LLBLGen bug but a breaking change in the Oracle driver. However, I'm unsure now what the best approach is. Can or should I workaround it, for example, using a TypeConverter? Or maybe you have the possibility to better react on this directly in the LLBLGen framework?

Best regards,
Markus

How unexpected, a breaking change that's not documented in the oracle ado.net provider... (this happened before, it's so frustrating).

Anyway, I think the cleanest is to use a type converter, as you can add that to your project and it will keep on working. The other way would be to change the mapping in the Oracle for ODP.NET driver of llblgen pro using the source archive. The downside of that is that when we ship a new version you have to update your driver again.

So I'd first try the type converter. (and document locally that the type converter is needed when using odac v23+).

Yes, very annoying, but thanks for the info.

In the best case I find a solution which works for both driver versions (21 and 23). And to be honest, DateTimeOffset for TimestampTZ columns makes in the end more sense since we don't loose the timezone information with this type. So I target having DateTimeOffset as type for properties mapped to TimestampTZ columns.

Therefore it is probably a combination of both (Oracle driver mapping update + type converter) or also maybe a project type conversion does the trick. I'll check it out.