Subject Re: [IBO] Integer Overflow Exception
Author Helen Borrie
At 09:45 AM 14/03/2006, you wrote:
>Hi there,
>I converted a BDE / FB 1.51 (Dialect 1) application to IBO 4.6.A / FB
>1.53 (Dialect 3).

Are you sure you converted the database? To make a dialect 1
database into a dialect 3 database, you would need to recreate the
database in dialect 3 and pump the data. If you merely restored a
backup, and/or used gfix to change the dialect, the data are *not*
converted from dialect 1 to dialect 3.

>The application used one TDatabase and many TQuery objects in a
>which were converted to their TIOBDataBase and TIBOQuery equivalents.
>The queries do nothing fancy, mainly selects and some parametrized
>insert / update statements.
>At first glance the application seemed to work as well as before, but
>after a longer test period the exception 'Integer overflow' occurred
> saving data to the database.

What is the exact message?

>The exception always occurs in line 3242 in unit
>IBODataSet.InternalGetFieldData at the following statement:
> tmpData := pointer( longint( ARecBuf ) +
> longint( SQLData ) -
> longint( InternalDataset.Fields.RowBuffer ));
>This function is called by TIBODataset.GetFieldData, line 3220 in
>The exception does not always occur after saving the same amount of
>Sometimes it occurs after saving ten times, sometimes I can save fifty
>or more times
>data to the database, but sooner or later the exception occurs.
>Does anybody have a clue, why the 'Integer Overflow' exception is raised
>by IBODataSet?

First, let's be clear whether the message is coming from Delphi or
from the database. Report the exact message, including its identfier
and any numbers you see in the message output.

>I am using Delphi 5 and IBO 4.6.A. As already said, I use FB 1.53
>(SuperServer). The database is dialect 3.

The symptoms you describe seem, on the surface, more like a mismatch
between the client dialect and the data stored in the database so,
e.g., you are going to get overflow of fixed numerics at a much lower
precision than if the data were in the format that the client
interface expects.

>If it helps I can provide a (madExcept) stack trace of the situation
>when the exception is raised.

Could be useful if you are able to eliminate the causes mentioned above.