Hi,
we are developing database application in Embarcadero Delphi XE using DOA 4.1.2.2. It worked fine for years. However after upgrading to Oracle 19 we are experiencing problems with corrupting (some) numbers passed as bind variables on client machines with AMD processor. We have traced down this error to be issue concering OCI function OCINumberFromReal when called from pascal code. We have tried to replicate the error using Visual C but it worked without any problem. This error can only be reproduced using Embarcadero Delphi or Free Pascal.
Here is a sample code demonstrating this bug using Embarcadero and plain oci library:
Sample code

When converting for example 369.0 number to internal Oracle representation we are excpecting a following result
as described in Oracle documentation

The example program result is:
3,194,4,70 (correct) when executing on machine with Intel processor or OCI version below 19
4,194,4,69,101 (wrong) – when executing on OCI 19 or newer and AMD processor - corrupts number passed to database!

We have created a service request at Oracle Support page but they seem to blame pascal - not their OCI.
That's why I am posting here. Does anybody experienced similiar issue? Is this strictly a pascal-dll call problem? Can anybody suggest any compiler settings that can help here?

Regards,
Marek

Note: Problem can be also observed on different number as 193.0, 194.0 but not on 191.0 for example.

What happens here is that the statement 'select dump(369.0) from dual' is sent to the server. The server then returns a varchar2 result like 'Typ=n Len=n: byte, byte, ...'. I'm not sure how "Pascal" could affect this outcome. The host language cannot invent these different bytes, and there is literally zero interpretation of data types. Just a literal string that is passed to the server for execution, and a literal string that is returned by the server.

Hi Marco,
my apologies for not beeing clear enough. I have included 'select dump(369.0) from dual' statement just to demonstrate beyond any doubt what a proper results of converting 369.0 to Oracle internal format should be.
The actual problem has nothing to do with select statement or any server side code. The actual problem is about preparing a FLOAT variable to send it as NUMBER bind variable to Oracle database. It takes place on client side when calling OCINumberFromReal function.
The code (provided as 'Sample code' link above) converts 369.0 number into Oracle representation to prepare it to send it as bind variable to database. It uses plain oci.dll library in the way the DOA do. I expect the code to produce result: 3,194,4,70. But when using OCI19+ (19.6, 19.9, 19.8) on AMD machines I get other result: 4,194,4,69,101. If such "bad" number is sent to database through a bind variable it corrupts the data. It is then impossible to select it or use it in a where clause and get proper query results.

We have also tried to reproduce the error on Intel client machines or Visual C or any OCI version below 19 but we failed. The problem occured only on OCI19+ with AMD client machines when using pascal environment (Embarcadero or Free Pascal) .

Regards,
Marek

And it still happens today on 19.20 (!!) - we are facing the same problem on a cloud environment that uses AMD EPYC processors.
On our ERP database, another real life efect is querying a single record: select * from table where my_key = :param - if param is otInteger, row returns OK - just change it to otFloat, zero rows found - what ?!
Oracle patch applied only on windows client 32, since we where getting random acess violation on oracle client DLLs - that stopped,but gives this another bug; the server side is untouched at original 19.3 linux x84 standard instalation.

I found an Oracle patch for this that seems to work - but no README available, nor installation instructions - OPatch does not like it ... so extracted from instantclient.zip (?) into orahome\bin ; my previous 19.20 now have a 19.19 oci.dll (hmmm...) and pass that tests from Marek and mine for our ERP.
Patch 35353768 and Note on Doc ID 2978992.1