I got your sample of the problem.

It was bizarre, I was starting to think I was going crazy.
StrToFloat was failing and I could not work out why.

'OCW' - whoever that is, put in some processing that overrides
the global DecimalSeparator but did not initialise the value,
or publish it to allow changes from the designer (or at run
time for that matter).

This results in DecimalSeparator being set to null during the
export process. StrToFloat relies on this value, and it also
relies on a null terminator on a string. With an integer value
it gets to the end of a string at the same time that it looks
for the decimal. The null terminator equals the decimal
separator value so StrToFloat thinks it has found a decimal
and keeps processing past the end of the string!

I am guessing that the OCW changes are recent (its only a guess
since there is no change detail at the top), which is why they
do not effect IB_SQL (have not been compiled into that yet).
The error is also rather inconsistent, presumably because
there are sometimes more than one null terminators at the end
of the string value. For example I was able to an export of
integer values from the employee database without seeing the
error at all.

Anyway...

Not sure if you can do this with the demo distribution of IBO
or not, but I believe you do have the source for IB_Export so
it may work.

Edit IB_Export and comment out every line containing
assignments to or from DecimalSeparator (there are three
lines).

Recompile and it works (or it did for me).

Anyone else using IB_Export should do the same thing. The
code that is there does nothing useful at the moment anyway,
so whoever it was that wanted this capability can try again
later.

--
Geoff Worboys
Telesis Computing