Subject | Re: [IBO] Why can't I delete or append my query? |
---|---|
Author | Helen Borrie |
Post date | 2002-12-08T21:32:25Z |
At 10:46 AM 08-12-02 -0800, you wrote:
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.
customerid: just set its VISIBLE attribute to false in your GUI.
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
>I didn't have KeyLinks explicitly defined, but I had KeyLinksAutoDefine setYou have two problems:
>to True. I tried explicitly setting it, but I get the same error.
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:Both. Include both columns in your query. You don't have to display the
>
>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?
customerid: just set its VISIBLE attribute to false in your GUI.
>If I putAre you talking about the same dataset, that contains a joined column? if
>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?
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