What I recommend at this point is that you create a separate simple instance
of this foul behavior. If you can isolate it out into something I can look
at and see where IBO isn't doing the "common sense" thing I will be all to
happy to make it work as you expect.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "ehandbury" <ehandbury@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, May 15, 2002 10:09 PM
Subject: Re: [IBO] OnBeforePost called twice (CallStack attached)


> --- 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
> ----*/