Subject RE: [IBO] Join edit
Author Helen Borrie (TeamIBO)
At 07:50 AM 16-01-02 -0800, you wrote:
>Helen, would the following sequence of events be correct :-
>
> 1 . switch off the readonly for the fields in join table in the afteropen
>event.

NO. If you have your UpdateSQL properly implement, all the fields will be writable. (You can switch readonly ON for fields that are otherwise writable; but you can't make a non-writable field writable by setting ReadOnly False!!)

> 2 . set the KeyRelation to one of the tables.

No. Only use KeyRelation to have automatic InsertSQL done for you on one table by the component, based on the fields in the KeyRelation table and the appropriate KeyLinks. If you want the WHOLE dataset to be updatable, you can't use auto updatesql AT ALL.

> 3 . allow the user to edit these in the grid. KeyLinks will take care of
>the linking

In the case where you are using KeyRelation and updating only one of the underlying tables, it's true that the KeyLinks have to be correct for IBO to position the update on the correct record.

> 4 . use the SP to effect the insert into the other table.

No; either
(a) Use a KeyRelation and update only one table - this makes the fields from the KeyRelation table live for editing and those from the other tables read-only.

OR

(b) Use EditSQL to call a SP to update all tables, using input parameters from the dataset. This makes all columns from all underlying tables live for editing.


> 5 . set readonly to true in the afterpost event.

Not valid. If a column is read-only by "SQL rules" then the client has to fudge "writableness" by replacing the respective straight INSERT, UPDATE and DELETE statements with procedural DML that the database engine won't reject. There is a heck of a lot of logic back there in the IBO components to do this fudge.

It will all work out if you make sure you isolate all the SQL inside a single transaction.


>I have a problem setting readonly to false. Is there a way to set this read
>only value other than changing the source? There should be no problem using
>TLookupCombo with this scenario, should there?

See above. No column can be made "not-readonly" if you have no code in the dataset's properties to make it updatable. Lookupcombos will only work on columns that the dataset sees as writable. Changing the source won't fix anything - it won't change the way the database responds to a request to "update" virtual data.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com