Re: Another VFP8 SP1 R.I. Builder BUG
From: William Fields (Bill_Fields_at_azb.uscourts.gov)
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.
-- 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" <firstname.lastname@example.org> 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 >