At 03:27 PM 28/05/2003 +0000, you wrote:

>I'm using Interbase. I don't use compound indexes but only in a
>handful of tables.

Compound indexes are not the same as keys. Are you implying that you have
no primary keys defined for your tables?

>The table I'm using doesn't have compound
>indexes.

Irrelevant.

> I do however have joins in nearly all of my queries. But
>shouldn't it be able to get the primary tables primary key for the
>keylink?

There is no such thing as "the primary table". In relational database
terms, a primary table is one which is not dependent on any other tables
for its existence. Generally, it implements a primitive entity from your
data model. This has nothing to do with identifying the keys for KeyLinks.

For joined sets, you always have to define Keylinks manually.

>Give me the rule of how to manually create the KeyLinks.

You have to work out and list the complete set of output columns which,
together, uniquely define one row of your output set. For a 2-table join,
this will usually be the primary keys of both contributing tables, if both
columns are in the output set. For outer joins and more complex joined
sets, it is much more complicated. There is no "magic rule" - it requires
human intervention in the form of your knowledge of the structure of your data.

For joined sets, you must include table identifiers in your KeyLinks. For
a set derived from a single table, it is optional.

Here's a very simple 2-table example to get you started. Both tables have
primary keys named pk.

select a.pk, a.field1, a.field2, b.pk, b.fielda
from atable a
join btable b
on a.field1=b.fieldb
where.....

Keylinks:
atable.pk
btable.pk

I see that your question started out with the topic "Refresh Single
Record". You actually have a great deal more work to do if you are trying
to perform updates, inserts or deletes on joined sets, since they are by
nature not updatable. You can make them so in IBO in one of three ways,
depending on what you need to update:

If you only want to update columns derived from one table, you can set
RequestLive true and name that table in the KeyRelation property. You
can't delete via this method because it would break the join; and you
can't insert by this method because it would imply a joined structure that
does not exist.

If you want to delete or insert rows, or update fields in more than one
table, then write parameterised stored procedures for them and make an
EXECUTE call to the procedures in the DeleteSQL, InsertSQL and EditSQL
properties respectively. The KeyLinks of the dataset must be among the
input parameters of the stored procedure. If you use the same name for the
input params as the column names in the dataset, IBO will pass them
automatically when the respective methods are called. If not, you will
have to assign the params explicitly in your code.

We seem to be getting to the bottom of your "lost" records. They weren't
actually lost, because they were never capable of existing. I'm curious to
know whether you ever saw any exceptions when trying to post.

hth,
Helen