DB/2 error CLI0102E SQLSTATE 07006 for TSession.Execute with TIMESTAMP parameter

[Former user]

procedure TToDo.SetBearbeitungTimeStamp;
var
  aBearbeitungTS: TDateTime;
  aIdx: Integer;
begin
  aBearbeitungTS := TimeStampCutSecondsAndMillis(Now);

  aIdx := 5;
  FDB.Execute('UPDATE TODO.TODOLISTE ' +
    'SET BEARBEITUNG = :0 WHERE INDEX = :1',
    [aBearbeitungTS, aIdx]);

  // this is forwarded to a TSession.Execute call of the
  // method TSession.Execute(const sql: string; const params: array of const): NativeUInt;

end;

In the DB/2 database, BEARBEITUNG is a TIMESTAMP field, INDEX is an integer field

Exception is thrown:

Erste Gelegenheit für Exception bei $7592C42D. Exception-Klasse EDB2NativeException mit Meldung '[FireDAC][Phys][ODBC][IBM][CLI Driver] CLI0102E Ungültige Umsetzung. SQLSTATE=07006'.

[Stefan Glienke]

I am sorry but DB2 is not officially supported by us right now.

What exactly does that error raised by the CLI driver mean?

[Stefan Glienke]

I looked a bit into it and it seems to not be related to DB2 alone but to the signature of TSession.Execute. The params array is an array of const which does not keep information about a TDateTime being passed but reports it as float. I will change this to an array of Variant and see if that fixes the issue.

[Markus Schadegg]

I just had a similar problem with sqlite:

A TTime or TDate value was saved as a float by TSession.Save.

[Column('DATE1')]
property Date1: TDate read GetDate1 write SetDate1;

[Column('TIME1')]
property Time1: TTime read GetTime1 write SetTime1;

sqlite> .dump

CREATE TABLE table1(IDX integer not null primary key autoincrement, date1 date, time1 time);

INSERT INTO "table1" VALUES(27,42160,7.26636192128353286534e-01);

should be something like:

INSERT INTO "table1" VALUES(27,'2015-06-05','17:07:26');

[Stefan Glienke]

I am not sure if that is the same issue. Can you provide some more information where you got that behavior? Because TDBParam.FromTypeInfoToFieldType should turn a TDate and TTime into the correct field types.

So my guess would be that it lies somewhere in the SQLite code. Can you look into TSQLiteDataset.DoInitFields to find out if there is anything going wrong?

[Markus Schadegg]

The issue, that I had, was just in a small testing project, that I made to have a look at spring.persistence... Maybe I got to re-test this in the current version... But actually, I have no time for further testing. Sorry.

Anyway, I wanted to help you by telling you about it... For me it seems, that there are (or were) some issues with the field-type-mapping of spring.persistence.

If I will have more time for further testing, I will try to reproduce the issue again.

[Stefan Glienke]

The issue with TDate and TTime in SQLite seems to be fixed and the reported never responded back so I am resolving this now.