Thanks, Helen! I set KeyRelation, and added both key fields to the
select. Works like a charm!

-Joe

At 08:32 AM 12/9/2002 +1100, you wrote:

>At 10:46 AM 08-12-02 -0800, you wrote:
> >I didn't have KeyLinks explicitly defined, but I had KeyLinksAutoDefine set
> >to True. I tried explicitly setting it, but I get the same error.
>
>You have two problems:
>1. A joined dataset can be made updatable in one of two ways, either:
>
>a) If you only want to update one table, set the KeyRelation to the name
>of the table which your app will update; or
>b) If you want to update multiple tables, write executable stored
>procedures to perform this work and use the xxxxSQL properties to invoke
>each proc (one each for insert, update and deletel).
>
>2. With KeyLinksAutoDefine set on a joined dataset, IBO will use the
>DB_KEY as the Keylinks. This may be OK if you are using method 1 b) for
>your DML. However, if you don't have your primary key columns in the
>dataset, even this won't work, because the SPs need to receive parameters
>from the dataset in order to find the underlying rows to update. The
>DB_KEY can't do this.
>
>
> >Actually, this brings up another question for me about KeyLinks:
> >
> >My table has a 2-field primary key (customerid and barcode), and some other
> >fields. My query selects all of the fields, except customerid, which is in
> >the Where clause (I'm selecting all records for one customer). What would
> >I set KeyLinks to? Just barcode, or both customerid and barcode?
>
>Both. Include both columns in your query. You don't have to display the
>customerid: just set its VISIBLE attribute to false in your GUI.
>
> >If I put
> >both in, I get an exception saying the customerid is invalid, I presume
> >because customerid is not in the select list. I can set it to just
> >barcode, and it accepts it. Barcode doesn't uniquely identify the row in
> >the whole table (the same barcode could exist for another customer), but it
> >IS unique for this dataset (where customerid is specified in the where
> >clause). Could this be the source of my problem?
>
>Are you talking about the same dataset, that contains a joined column? if
>yes, then it is *part* of your problem. The other part of it is that the
>uniqueness of the keylinks needs to take in the joined table as well - so
>you would need to add the PK of the joined table as well.
>
>There may be a third piece to this problem, if your join statement uses the
>old implicit join syntax (select blah... from tableA, tableB). In that
>case you would also need JoinLinks to tell IBO which output columns are
>used for the join. If you use explicit join syntax (select blah...from
>tableA JOIN tableB ON....) then you don't need JoinLinks.
>
>If this single lookup column is read-only in your app, then a better way to
>get it would be to use a subselect. It then comes into the output set as a
>computed column (remember to set its COMPUTED attribute to true) and you
>don't have the overhead of the join processing.
>
>Helen
>
>
>
>___________________________________________________________________________
>IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
>___________________________________________________________________________
>http://www.ibobjects.com - your IBO community resource for Tech Info papers,
>keyword-searchable FAQ, community code contributions and more !
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/