Beware of trying to use TopDown_BottomUp or any of the other variants if 
the master window is shared to a Datastore. What actually happens is that 
the Datastore (n_ds) SqlPreview event is run which has its own 
is_updatesallowed variable.
I get around this by Overrideing the master DW (u_dw) pfc_update event with 
the following:

===============================================
// OVERRIDE
// to allow linkage deletes to work, need to overide this and call
// n_ds version instead (due to sharedata)

integer li_rc

// Verify passed arguments.
IF IsNull(ab_accepttext) Or IsNull(ab_resetflag) Then Return -1

// Call for PreUpdate functionality - in case it is used
If this.Event pfc_PreUpdate() < 0 Then Return -1

// Call n_ds to do the update
li_rc = gnv_app.ids_blah.of_Update(ab_accepttext,ab_resetflag,  &
                                     Pos(is_updatesallowed,'I') > 0,    &
                                     Pos(is_updatesallowed,'U') > 0,    &
                                     Pos(is_updatesallowed,'D') > 0)

Return li_rc
================================================

Regards,
   Gary Hyland
   Australia

-----Original Message-----
From:   Laforce, Lester [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, September 15, 2000 4:59 AM
To:     'PFCSIG'
Subject:        PFCSIG TOPDOWN_BOTTOMUP Linkage Update Style


I'm attempting to implement the Linkage Service's TopDown_BottomUp
UpdateStyle (we're planning to use it to implement cascading deletes).

I'm certain I've correctly coded the initialization of the Linkage Service,
the registration of the various DWs and correctly initialized the
UpdateStyle.

In testing, I've inserted a row in one of the child DWs and then called
pfc_Save().  Everything seems to be working correctly except that the DW
Update() function is being called twice for my child DW and the second call
is causing a Duplicate Primary Key error.

This is, of course related to the fact the TopDown_BottomUp EditStyle does
its update in two passes, a TopDown pass and a BottomUp pass.

In the PFC, the SQLPreview event is supposed to provide selective updates,
inserts, and deletes.

In the case of an Insert, the second pass is trapped by the SQLPreview 
event
and the update suppressed by having SQLPreview return a 2.

The documentation says; "return 2 = Skip this request and execute the next
request"

In the debugger I can see. the event returns the correct value (2), but the
request is not skipped, thereby causing the DB error.

Does anyone have  any suggestions? We are using PB6.5 with a MS SQL Server
6.5 back-end.

Lester LaForce
[EMAIL PROTECTED]
Sr. Software Developer (Contractor)
Future Technologies, Inc.
Armed Forces Institute of Pathology
Washington DC


> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, 
ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE:   help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE:   help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]

Reply via email to