On the lost record question. I guess I didn't specify that the
records where just being filled into the client dataset they were
actually in the database and visible up until the time that I called
the invalidatebuffer. This was being done after the record was
already posted and confirmed to be in the database.

The KeyLinks problem was preventing the InvalidateBuffer from being
able to locate the record to reload it into the client dataset.

Thanks again.

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