Re: Another VFP8 SP1 R.I. Builder BUG

From: William Fields (Bill_Fields_at_azb.uscourts.gov)
Date: 03/12/04 

Date: Fri, 12 Mar 2004 09:15:39 -0700

Hi Igor -

> *IK* Have to switch to RI temp cursor workarea !!!
> SELECT (m.lcNewWkArea)
> *IK* The end of fix :)

Yes, that's the fix. Simple enough, but it would need to be "fixed" any time
the R.I. builder regenerates the SP code in the database.

Regards, 

-- 
William Fields
MCSD - Microsoft Visual FoxPro
MCP - Win2k Pro
US Bankruptcy Court
Phoenix, AZ
"Don't look back - we're not going that way."
        - Terry Hunefeld
"Igor Korolyov" <k1i2v3@km.ru> wrote in message
news:Oyq9AvBCEHA.3784@TK2MSFTNGP10.phx.gbl...
> Hi, William!
> You wrote  on Fri, 5 Mar 2004 12:00:57 -0700:
>
> WF> Thanks Rick, probably should have checked out Steve Sawyer's R.I.
stuff,
> WF> but I thought I was good to go until now....
>
> It is really much better tool than MS RI builder. But it also have some
> minor problems/incomprehensibilities. Error handling is the one of them
(at
> least in version I have, maybe it was rewritten now to use try ... catch
> error handling system)
>
> WF> There's another deficiency in the referential integrity builder
> WF> generated code. This one has to do with a parent table that has 2 or
> WF> more foreign key fields (and associated R.I. rules) in a child table.
>
> Do you mean the bug that can be fixed with the following "fixed" RI code?
>
> =========Beginning of the citation==============
> PROCEDURE riopen
> PARAMETERS tcTable,tcOrder
>
> LOCAL lcCurWkArea,lcNewWkArea,lnInUseSpot,lnOccurs,lnOccurance
> lnInUseSpot=0
> lnOccurs = OCCURS(UPPER(tcTable)+"*",UPPER(pcRIcursors))
> FOR lnOccurance = 1 TO lnOccurs
> lnInUseSpot=ATC(tcTable+"*",pcRIcursors,lnOccurance)
> IF ISDIGIT(SUBSTR(pcRIcursors,lnInUseSpot-1,1)) OR;
>  EMPTY(SUBSTR(pcRIcursors,lnInUseSpot-1,1))
> EXIT
> ENDIF
> lnInUseSpot=0
> ENDFOR
>
> IF lnInUseSpot=0
>   lcCurWkArea=select()
>   SELECT 0
>   lcNewWkArea=select()
>   IF NOT EMPTY(tcOrder)
>     USE (tcTable) AGAIN ORDER (tcOrder)
>       ALIAS ("__ri"+LTRIM(STR(SELECT()))) share
>   ELSE
>     USE (tcTable) AGAIN ALIAS ("__ri"+LTRIM(STR(SELECT()))) share
>   ENDIF
>   if pnerror=0
>     pcRIcursors=pcRIcursors+upper(tcTable)+"?"+STR(SELECT(),5)
>   else
>     lcNewWkArea=0
>   endif something bad happened while attempting to open the file
> ELSE
>   lcNewWkArea=val(substr(pcRIcursors,lnInUseSpot+len(tcTable)+1,5))
>   *IK* Have to switch to RI temp cursor workarea !!!
>   SELECT (m.lcNewWkArea)
>   *IK* The end of fix :)
>   pcRIcursors =
strtran(pcRIcursors,upper(tcTable)+"*"+str(lcNewWkArea,5),;
>     upper(tcTable)+"?"+str(lcNewWkArea,5))
>   IF NOT EMPTY(tcOrder)
>     SET ORDER TO (tcOrder) IN (lcNewWkArea)
>   ENDIF sent an order
>   if pnerror<>0
>     lcNewWkArea=0
>   endif something bad happened while setting order
> ENDIF
> RETURN (lcNewWkArea)
> =========The end of the citation================
>
> WF> The problem occurs during the second field R.I. validation code (error
> WF> #12 "Variable not found"), but the ON ERROR statement in force during
> WF> the R.I. code basically ignores it.
>
> WF> The problem rears it's head if the object issuing the TABLEUPDATE()
has
> WF> code in it's .ERROR() method. Since an object's .ERROR() method
> WF> supersedes any active ON ERROR statement, the object's .ERROR() method
> WF> it will fire and it's up to you to deal with it. We had to modify our
> WF> error handling code to ignore this particular error like the R.I. code
> WF> does.
>
> I don't know any way to fix _this_ problem _internally_ (in SP code
itself),
> other than migrate to VFP8 and rewrite the RI code to use try ... catch
> error handling.
>
> -- 
> WBR, Igor
>

Relevant Pages