Page 1 of 1

Overflow error deleting a record

Posted: 14.03.2009, 21:24
by alquimista
Hi,

Using Delphi7-MySQL 5 ... I have this:

CREATE TABLE `banco` (
`banco_id` bigint(20) NOT NULL auto_increment,
`ban_numero` smallint(6) NOT NULL,
`ban_nombre` varchar(80) NOT NULL,
PRIMARY KEY (`banco_id`),
UNIQUE KEY `ban_unq_numero` (`ban_numero`),
UNIQUE KEY `ban_unq_nombre` (`ban_nombre`)
) ENGINE=InnoDB AUTO_INCREMENT=689349199046620195 DEFAULT CHARSET=latin1;

I have a ZQuery component connected to a DataSetProvider and then a ClientDataSet

When deleting a record I get:

"Overflow while converting variant of type (Int64) into type (Integer)"

The code I used to delete the record is:


DataSource.DataSet.Delete;

if TClientDataSet( DataSource.DataSet ).ApplyUpdates(0) > 0 then
TClientDataSet( DataSource.DataSet ).CancelUpdates;

On a previous version of the program, I connected the DataSource directly to the TZQuery and I didn't have this problem. I added Provider and ClientDataSet since I need functioanlity of these...

I suppose this problem is related to the PK field "banco_id", being bigInt? what internally would be treating it as Integer data type?

Thank you,

Posted: 14.03.2009, 23:38
by alquimista
Debugging a bit deeper, I found that:

In ZAbstractDataSet.pas, there is this block of code, starting at line 677:


for I := 0 to Length(FieldRefs) - 1 do
begin
SrcField := Delta.FieldByName(TField(FieldRefs).FieldName);
if SrcField <> nil then
begin
if (SrcField.DataType = ftLargeInt)
and not VarIsNull(SrcField.OldValue) then
Temp := Integer(SrcField.OldValue)
else Temp := SrcField.OldValue;
end else
Temp := Null;
end;

On the marked line, the db table's id field its being tryed to be converted into an Integer (32 bits), when it is required a 64 bit number...

Is it a bug?

Posted: 21.03.2009, 00:01
by mdaems
It may very well be. Did you try to replace it by substituting a bigger Integer type (Int64)?

Mark

Posted: 21.03.2009, 20:05
by alquimista
Yes, it was a bug. I replaced the code with Int64 type and now it works.

Posted: 21.03.2009, 21:29
by mdaems
I replaced the code with Int64 type and now it works.
How did you do that?
Temp := Int64(SrcField.OldValue) doesn't seem to compile on Delphi7 ?

Mark

Posted: 21.03.2009, 21:36
by alquimista
File ZAbstractRODataSet.pas, Line 3024:

Changed from
Statement.SetInt(I + 1, ParamValue.AsInteger);
To
Statement.SetLong(I + 1, StrToInt64(ParamValue.AsString));

File ZAbstractDataSet.pas, Line 688:
Changed from
Temp := Integer(SrcField.OldValue)
To
Temp:= string(SrcField.OldValue);


Regards,
Guillermo

Posted: 21.03.2009, 21:49
by mdaems
Looks very unconventional. Running the test suite now.
Does somebody know if there are more recent compilers where Variants can hold Int64 values? Which Delphi or FPC versions? In that case we should $IFDEF the code in a way only the older compilers use this string conversion technique.

Mark

Posted: 21.03.2009, 22:02
by mdaems
Didn't break the test suite. So I commit to SVN Testing branch (Rev. 608). Before this is backported to the 6.6-patches branch I want some more people to give feedback on this topic.

This patch impacts all people using bigints as key fields, I think. I suppose most people don't run into problems as long as the key stays withing the Integer range?

Mark

Posted: 22.03.2009, 09:34
by mdaems
Got some stupid idea. Seems like Variants can be Int64 values as well in D7. (When quick scanning the variants units)
Wouldn't it be better we just remove the
if (SrcField.DataType = ftLargeInt)
and not VarIsNull(SrcField.OldValue) then
Temp := Integer(SrcField.OldValue)
else

part from the code? At least in the Zeoslib 7.X version, 6.6 should in theory be able to compile on D5, where Variant support was still primitive, I believe.
Can you do me a favour and try this with your test program/data?

Mark

Posted: 24.03.2009, 03:30
by alquimista
I eliminated the block of code you suggest and recompiled ZAbstractRODataSet.pas; the system seems to work Ok.

Posted: 25.03.2009, 21:37
by mdaems
Committed this change to SVN (Rev 612).

Still looking for somebody else's opinion on if and how we should add the first patch to Zeoslib 6.6-patches branch.

Mark