Hi Helen,
thanks for an excellent and thorough reply (even through my
confusion!!)

Your explanation on master linking datasets makes perfect sense now,
as to why the triggered ID could not be seen. (both master & detail
ARE in the same transaction)
I will use the gen_id() to get the proper ID. My generator is
already set up to handle new ID's only if the field is null.

My way of thinking was a bit back to front, hence the confusion.

> Your description is very confused. You said you are importing
> records. How come you are trying to do this through a master-

detail

> structure anyhow?

My application can generate a simple text file (from a
master/detail), which can then be imported by the same app on
another machine. As it exports master & detail records, I need to
import both master & details records.

> As a further comment on all this confusion, you wouldn't normally
> use TIB_Cursors to hold master-detail sets if you are using

MasterSource

> and MasterLinks, since these don't return scrollable datasets...

I was using TIB_Cursors as I was under the impression they were
faster, and as I wasn't going to use them to display the data, I
thought it would have been beneficial. (Which it still is, now that
I can use gen_id())

> Grab the TI sheet on Master/Detail from the TechInfo page.

Have read it. Helped a lot (like all articles on that page).
I just didn't know how to use gen_id, away from the trigger. To be
honest, I didn't even think of that.
I'm coming from a BDE background, so most stuff makes sense, I'm
just a little slow getting the conceptual change happening in my
head!

> I think what you mean to say is that you are creating the

components in

> run-time, rather than in design-time.

Thats exactly right. I only like having fundamental components for
the app. Most "data-shifting" and other queries I generate at run-
time.

Again,
thanks for an excellent reply. I've read many of your replies, and
learnt a lot. Like now! :)

Rgds,
-Ryan