Oops sorry forgot to respond to the index/key thing. I termed that
wrong. Yes I have a PRIMARY KEY on all of my tables. I understand
that INDEXES are different from KEYS just a slip of the tounge.

Matt

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> 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