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

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 09:36 AM 26/05/2004 +0100, you wrote:
> >In article <200405251810510987.061ED001@s...>, Dan Wilson
> >wrote:
> > > Are there any gotchas I should be aware of regarding creation

and

> > storage of records into external tables?
> > >
> >You need to allow a character in the table defn for the newline

(and CR

> >depending upon platform)
>
> Well...no, you don't. You can include it if the file you are

reading has

> it, or if you are exporting to a file to be read by an application

that

> needs it.
>
> I think the problem here has to do with the precision of the
> doubles. External table rows have to have fixed length fields and

I don't

> see how you could predict the length of floating point numbers

imported

> from an external source directly. How would the field boundaries

be

> determined?
>
> /heLen