On 5/26/2004 at 10:58 AM Ali Gökçen wrote:

> No, it is not about precision bacause it is a binary data and
> there is no precision format in FB table. it only a 8 byte moving to
> another 8 byte field.
>
> I think problem is about last three int field at the bottom.
> there is no information about the Dan's C++ compiler and word size
> of CPU running mode.
> i think the last three int fields are may be 2 bytes integers, but
> FB's INTEGER are 4 bytes.
>
> Regards.
> Ali
>

You are correct regarding the double precision fields: they go across as 8-byte entities, and since I am not transferring between processor families they should be fine (and indeed, isql shows the right values placed into the proper columns).

The three int fields are not the problem: the compiler is Borland C++ Builder 6, an int is 4-bytes (32-bits). The smallint's are 2-bytes (16 bits). All of those fields transfer correctly, and all fields behind them also transfer correctly. For the first record. The second one fails.

> Sorry, i forgot to talk about another possibility,
> if your database has default character set other than 1 byte coding,
> FB will try to read your external file more than 20 bytes for
> szCreationTime field it causes overflow.

The entire database is set for character set NONE.

Regards,

Dan.