> 1) What are the diff's / benefits of using OrdringLinks over an
> ORDER BY clause in the SQL?

You can have multiple ordering definitions and easily switch between
them using the OrderingItemNo - including switching between custom
ascending and descending ordering. In addition the orderinglink
properties interact with IB_Grid to visually show ordering and changes
to ordering possible via click on the column titles.

There are some other coding advantages as well - since more is known
and can be determined about ordering generated from orderinglinks
rather than ordering explicit in the statement itself.

> 2)Why does my trigger not appear to fire? I have got around this
> using GeneratorLinks, but does the TIB_Query not see all the
> metadata?
> 3)As triggers do not fire, do SP's not get called either?

The triggers do fire. I am guessing that they are just not firing
when you expect them. Note that the server does not have "insert" or
"edit" modes, these are client application concepts. When you put a
dataset into "insert mode" the server knows nothing about it. When
you post the inserted data then the server gets to see an insert
statement and the triggers fire. So the before insert trigger fires
when the inserted record is posted (just before the data is written),
and not when the client simulates an "insert mode".

If that does not explain what you are seeing we will need more info.

> 4)Why is the KeyLinks value needed for a query to be editable?

Technically you dont. You can just create an UPDATE or INSERT sql
statement and fire it at the server, presuming the statement is valid
and contains all required fields then it will work. BUT...

How do you see the results of what you just did? Without knowing the
key value of the record you just inserted/updated you cannot read it
back (reliably) to see what side effects may have be performed by the
triggers. If you dont know the key used to retrieve the record you
cant read it back - even if you read back the entire dataset you would
not know which was the record you just inserted/updated.

Indeed for BLOBs reading the record back is ESSENTIAL if you want to
be able to update the blob again later in the same session (because
the blobid used to track the data is actually altered during the
insert/update processing performed at the server).

If IBO did not have GeneratorLinks to create its own key values (where
that is the type of key used) then after an insert IBO would lose
track of the record altogether (how would it know what value was
generated by the trigger).

In addition the KeyLinks can be used to optimise queries - when you
set FetchWholeRows = false IBO builds two selections, one just for the
keys and the other to select one full record at a time using the keys.
This can have significant advantage over a slow link (and even on fast
links if there are many large records).

And further more the KeyLinks offer really useful bookmark facilities.
Rather than just being a number which may be invalid against other
datasets or in a later update on the same dataset, the bookmarks are
based on the true key link value and can be used across transactions.

The above presumes an interactive dataset, like IB_Query. You dont
have to use interactive queries - which is why the other components
exist (like IB_Cursor and IB_DSQL etc) and for these components the
KeyLinks are not essential.

> I know these questions are quite novice, but I'm coming from a
> paradox background and I'm getting adjusted with the conceptual
> shift.

It takes time, but IBO makes it worth it. Good luck.

--
Geoff Worboys
Telesis Computing