using Oracle 10g im accessing a table with an 'id' column of datatype NUMBER, data length 22, data precision 10 and data scale 0. The delphi app had previously been connected to a sybase database and cloumn 'id' was defined as an integer, so the column type for 'id' had been set to TIntegerField in the Delphi app. Now that im rebuiling the app to use the oracle database, i get an error telling me column 'id' is of type TIntegerField but should be type TFloatField. Surely the number column as previously defined equates to an integer. Is this a problem with DOA not being able to interpret the column type correctly ?

An integer field can be used for database fields upto a precision of 9 digits (2^31). For 10 digits the database can contain values that cannot be represented as a 32 bit integer.

However, if you are sure that the number(10) columns in the database will never contain values that are larger than a 32 bit integer, then you can set TOracleSession.Preferences.IntegerPrecision to 10 to get the desired behavior.

Same issue here. I understand the the problem. What I don't understand though, is the fact that this behaviour is depending on the oracle-version. With 9.0 I'm having no problems, from 9.2.0.6 up the above mentioned behaviour begins.
What is the trouble with filling a float with an integer?

There is no problem filling a float with an integer value, but unfortunately the standard TFieldDef class is rather strict when it comes to data types of persistent fields.

If differences occur between Oracle versions, then this is most likely a query with calculated fields such as aggregates (sum, avg, ...) or set operations (union, minus, ...). The differences occur for the scale or precision reported by Oracle, which in turn may result in a float or integer field in Delphi.

I am referring to this following issue (taken from the readme for patch 9.2.0.4):

[quote] 11.8 Event 10499

Event 10499 was introduced in release 9.2.0.3 to allow customers to revert to the earlier behavior of NUMBER datatypes that have no explicit setting of their scale value. Any non-zero setting of the event level will enable the old behavior.

Prior to the introduction of this event, server code could return zero for the scale if a NUMBER datatype was created without specifying the scale. Other code paths would return -127. With this event, all code paths return -127, as this is the correct behavior.

Client applications may rely on the previous (incorrect) behavior. Typically, client applications will test for a scale of -127 to distinguish between NUMBER and FLOAT datatypes. It is not sufficient to test the scale alone to distinguish between these two datatypes, one needs to test for a scale of -127 and a non-zero precision to identify a FLOAT.

Client applications that rely on the old behavior can still work as before if the event is set but will need to be corrected prior to upgrading to the next major release of the Oracle database.
[/quote]So now I have found a way to get the application back running, but what is bothering me is the last sentence... Will allroundautomations consider this, or must I change my applications?

Thanks
Sherlock

The current 4.0.6 already works as described above.

This is a serious problem for us, and it is not solved in the 4.0.7.1 version of DOA. I also tried this using both Delphi 6 and Delphi 2005, and this makes no difference.

The situation we have is the following: we have a number of queries using UNION, or based on views which in turn also use UNION. The application has been built and tested on Oracle 9. When testing it on Oracle 10, we get a "Type mismatch <..> expecting Float, actual Integer" error message.

Different customers use different versions of the Oracle platform, and we have a strict requirement that different versions of the application shall be backwards compatible. The number of queries involved is large. A simple search and replace of all floatfields converting them to integerfields is not feasible due to the backwards compatibility requirement and the differing oracle database versions at different customer sites. Also some of the floatfields actually are real floats. So we have a fairly complex situation.

I have been debugging a test application to try and find a way to solve this. The exception is raised from TDataset in DB.pas, from a protected, virtual method called CheckFieldCompatibility.

I tried to override this method and simply ignore the fact that the field definition was not the expected one, but the values shown in an ordinary dbGrid then came out completely wrong.

I then tried (still in the overridden CheckFieldCompatibility) to create a new field object with the same properties and events but with another field type, and delete the original field object. This also fails.

I tried a similar approach in an overridden version of the InternalOpen method, but at that point the FieldDefs are not available so this fails as well.

Is there anyone else with the same problem, and have you found a way to cope with this? Marco, will you please try to fix this?

With regards,
Helene

It is really an Oracle Client and/or Server issue, and a Borland VCL issue.

1. The field is reported with different scale and precision on different Oracle Server versions.

2. The TFieldDef class raises an exception when a persistent field does not match the database definition.

It's very unfortunate, but all you can do is avoid persistent fields in the specific case.

That is not a good solution for us either, since you must create persistent fields for ALL fields for a dataset, or for none. AND there are lots of property settings and event handlers set for the fields at design time.

I am posting a support case at Borland too for this problem. However, I am also testing another approach which seems to work. I override the doBeforeOpen method, detect the oracle version and if appropriate delete existing fields replacing them with fields of the correct type. This enables us to use persistent fields and maintain backwards compatibility.

With regards,
Helene

As I expected, Borland is not willing to see this as their problem either. They would rather have us look at ADO or dbExpress... which is not an option at all for us.

However, the approach described above does work quite well. Even if it is not the best way to solve the problem - I would have preferred a way to handle this at the dataset component level.

With regards, Helene