--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:

> If the detail dataset has its Post method called then it is the

detail

> dataset being posted and not the master. But, if the master is in

insert

> state then it should be clear to you that there isn't a record

which will

> serve as the master record in order to fulfill the relational

integrity of

> the relationship. (Yes, this is assuming everyone who does master-

detail

> relationships also does proper referential constraints.)
> So, by doing a PostRetaining of the master dataset the record is

actually

> inserted to the server in order to satisfy RI and yet the client

application

> has no visibly apparent evidence the master dataset produced the

insert.

> When the master dataset does get posted it will know it was already

post

> retained and so it will do an update instead of an insert in the

process of

> posting the dssInsert state.
>
> Does this make it more clear?

It's clearer, but I have found problems with this approach.
1) I am not posting on the detail, but on the master. Therefore,
IBO should do a full Post and then post the detail since I have told
IBO to post the master first.
2) Even if the initial post is on the detail dataset, the
insert/update sequence is contiguous meaning that no client code can
be executed inbetween the 2 posts, so why not have the smarts to
realize that if the master is dssInsert, then don't do the
PostRetaining. In my testing, the sequence is 1) master insert, 2)
detail insert, 3) master update.
3) A major byproduct problem is the issue of triggers. I now get
the after/before insert triggers called, then the after/before update
triggers called as for the same insert. I do alot of work in the
triggers and this is very problematic for me.
4) There is also a bug in the update statement. As you can see in
the Monitor output below the final MBACTIVITY update has
ALERTSTATUS=0 which is not the true value. I change the value of this
in the insert triggers. IBO is getting the value from the 'Default
Values' property, so its overwriting the value I changed in the
insert triggers. I have tried to use the BufferSynchroFlags to no
avail. Again, it seems like this is a byproduct of the
PostRetaining/Post sequence.

>
> What I said I should do when calling the Transaction Commit method

is have

> it so it will be a little more smart about how it will post all

datasets.

> Right now it just goes through a simple list posting as it goes

without any

> special considerations. So, if it happens to get to the detail

dataset

> before it gets to the master dataset and this condition exists it

will do

> the post retaining and subsequent post of the master. I am

suggesting that I

> put in the smarts to know if the whole transaction is committing all
> datasets that there really is no need for a PostRetaining to take

place but

> to just post the master dataset fully.
>
> Would that clear up your problem?

The above problems all occur when I post from the TIB_UpdateBar so
having these code changes in the commit code only would not help in
this case.

Thanks. Eric.

/*---
EXECUTE STATEMENT
TR_HANDLE = 17373456
STMT_HANDLE = 17377344
PARAMS = [ Version 1 SQLd 7 SQLn 7
MBCLIENT.CLIENTKEY = 9906
MBCLIENT.STATUS = 0
MBCLIENT.ALERTSTATUS = 0
MBCLIENT.FILENUM = <NULL>
MBCLIENT.LADATE = '16 May 2002'
MBCLIENT.CDATE = '16 May 2002'
MBCLIENT.NOTES = <NULL> ]

INSERT COUNT: 1

SECONDS = 0.010
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 17373456
STMT_HANDLE = 17377028
PARAMS = [ Version 1 SQLd 11 SQLn 11
MBACTIVITY.ACTDATE = '16 May 2002 14:33:25 3830'
MBACTIVITY.ACTIVITYKEY = 9908
MBACTIVITY.ACTIVITYITEMKEY = 1526
MBACTIVITY.SUBITEMKEY = 0
MBACTIVITY.CLIENTKEY = 9906
MBACTIVITY.USERKEY = 2042
MBACTIVITY.DESCRIPTION = <NULL>
MBACTIVITY.STATUS = 1
MBACTIVITY.ALERTSTATUS = 0
MBACTIVITY.LCDATE = '16 May 2002 14:33:25 3930'
MBACTIVITY.NOTES = <NULL> ]

INSERT COUNT: 1
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 17373456
STMT_HANDLE = 17374108
PARAMS = [ Version 1 SQLd 10 SQLn 10
MBACTIVITYFOLLOWUP.ACTIVITYFOLLOWUPKEY = 9909
MBACTIVITYFOLLOWUP.ACTIVITYKEY = 9908
MBACTIVITYFOLLOWUP.FDATE = <NULL>
MBACTIVITYFOLLOWUP.DURATION = 3
MBACTIVITYFOLLOWUP.PERIOD = 3
MBACTIVITYFOLLOWUP.COMPDATE = <NULL>
MBACTIVITYFOLLOWUP.COMPTIME = <NULL>
MBACTIVITYFOLLOWUP.INTERESTLEVEL = 0
MBACTIVITYFOLLOWUP.ASSIGNUSERKEY = 2042
MBACTIVITYFOLLOWUP.COMPUSERKEY = 0 ]

INSERT COUNT: 1

SECONDS = 0.030
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 17373456
STMT_HANDLE = 17382248
PARAMS = [ Version 1 SQLd 1 SQLn 1
[MLNK_CLIENTKEY_0] = 9906 ]
----*/
/*---
OPEN CURSOR
STMT_HANDLE = 17382248
NAME = C28708132571463122

----*/
/*---
CLOSE CURSOR
STMT_HANDLE = 17382248
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 17373456
STMT_HANDLE = 17375848
PARAMS = [ Version 1 SQLd 12 SQLn 12
MBACTIVITY.ACTDATE = '16 May 2002 14:33:25 3830'
MBACTIVITY.ACTIVITYKEY = 9908
MBACTIVITY.ACTIVITYITEMKEY = 1526
MBACTIVITY.SUBITEMKEY = 0
MBACTIVITY.CLIENTKEY = 9906
MBACTIVITY.USERKEY = 2042
MBACTIVITY.DESCRIPTION = <NULL>
MBACTIVITY.STATUS = 1
MBACTIVITY.ALERTSTATUS = 0
MBACTIVITY.LCDATE = '16 May 2002 14:33:25 3930'
MBACTIVITY.NOTES = <NULL>
MBACTIVITY.ACTIVITYKEY[ACTIVITYKEY] = 9908 ]

SELECT COUNT: 1
UPDATE COUNT: 1
----*/