The simple way to do this is using a TIB_Connection, TIB_Transaction and
TIB_DSQL. Connect the three of them together, open the TIB_Connection,
prepare the TIB_DSQL, and loop through your Paradox table assigning
Parameters to the TIB_DSQL and execute it. Then at the end (and optionally
for every 10000 records) call TIB_Transaction.Commit (no need to start the
transaction, IBO does this for you).

Whether a Commit was being called for every insert or not, I do not know.
Basically commits take quite a bit of time, so you would probably notice a
considerable speed improvement if changing from "commit per record" to
"commit at the end".

HTH,
Set

At 02:09 05.09.2002 +0000, you wrote:

>Hi there,
>
>I have just finished reading the chapter on Transactions in the IBO
>Getting Started Guide (a good read, and worth the money to anyone
>who is considering getting it), but still would like further
>clarification.
>
>I'm importing data from a paradox/bde app, using a TIB_Cursor (ibc).
>I assign my TIB_Connection to the cursor, then setup a parametrised
>query, and cycle through each paradox table record, and call Execute
>for the cursor, then move onto the next record, and so on.
>Once all records have been imported, I then call ibc.Commit
>What I would like to know is should I be using an explicit
>transaction to speed things up? I thought this was using an explicit
>transaction, until during the import, the routine stops due to an
>integrity problem on a unique record, before reaching the end of the
>import (i.e. the Commit never gets called) but when I inspect the
>table afterwards, all records up to the integrity violation are in
>the table.
>My understanding was that if it didn't get to the Commit, and
>crashed, the commit would never happen.
>
>So I'm assuming that an implicit Commit is being called with every
>Execute, and no doubt this has extra overhead.
>
>Is my understanding correct? Should I call StartTransaction
>explicitly to gain control?
>
>Thanks for any info.
>-Ryan