> In order to execute all scripts correctly 100% IBO's parsing is more
> comprehensive than IBX's is. This apparently has a performance price.
> Perhaps I need a property to flip parsing styles between comprehensive and
> simple... I could also just need to do a little profiling.

If you decide you want to do some profiling, I can provide a large sample
file.

> Why even use a script for inserts in the first place is the question you
> might want to consider.

The scripts we're using are for initial database population (IE to populate
our databases, either before we ship a new version, or for getting a clean
database for development purposes, etc), for the most part. We do have a
script running tool that works at a customer's site (You drop a file in the
directory, start up the tool, hit the big button, drool a bit, and close the
tool... Your updates are done. Perfect for the know-nothing customer. :))
Why not use a script for inserts? Or, what are the other possible ways of
doing things in IB/FB? External tables are a pain, because of fixed length
columns, as well as for supporting multiple databases.
The reasons we do are :

1. We need to support multiple databases (IB/FB, SQLServer, Oracle), because
of customer demand. Scripted inserts gives us the ability to keep
everything up to date by modifying one set of data insertion scripts. (Our
table creation is also done via scripts, but they're customized for each
database).
2. Scripts go nicely into CVS, making diffs easier. If you realize someone
screwed up and accidentally commited something (Or a few somethings) to CVS
they shouldn't have, you can figure out easily where the last good script
was, and go back to it. Any sort of binary files, not so easily done. And
yes, this has happened before. Not recently, thankfully.
3. They're convenient for doing database updates.

Believe me, we have considered it. :)
Nothing else (that we're aware of) will provide the flexibility we need
(albeit with a speed hit).

- Jason