Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Running Loosely Connected & row rule recursion
Message
De
07/02/2005 16:05:47
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivie
 
 
À
07/02/2005 15:53:15
Jill Derickson
Software Specialties
Saipan, CNMI
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 8 SP1
OS:
Windows 2000 SP4
Database:
Visual FoxPro
Divers
Thread ID:
00984403
Message ID:
00984571
Vues:
25
>Hi Hilmar,
>
>I know that, running interactively, i can change a value in the table, and the row rule causes the modNumber to be updated and all is well. So, one CAN change a field value in a record validation rule.

That may be so. However, I thought that changing the same record you are working on, in the validation, would always cause the illegal recursion.

I didn't try this; you might be able to trick VFP by re-opening the table you want to update, and searching for the PK. But if it works (i.e., VFP doesn't complain about illegal recursion) you must be very careful to take care of illegal recursion yourself: have the update depend on some condition in such a way that another update will not be triggered.

You might also try field validation vs. record validation vs. triggers.

>
>Running from my form, however, a view is used to do the update...will keep working on it...thanks, j
>>Hello, Jill.
>>
>>The "recursion" means the following. A record change fires a record rule validation. If this rule validation changes the record, this change, in itself, will again fire the validation rule - and so forth, ad infinitum, i.e., a senseless recursion.
>>
>>I know of no way to bypass this in a VFP table; what I have usually done in similar cases, is to make the corresponding from the form that changes the data.
>>
>>In your case, this is tricky, since you want to detect any change. However, you might consider recording changes (for example, write the PK and date changed) to another table - in this case, you should not get an illegal recursion.
>>
>>>Hi,
>>>
>>>I've taken some ideas from a July 2001 FoxPro Advisor article, "Running Loosely Connected, Part 3" to synchronize updates in tables between headquarters and remote locations.
>>>
>>>A "ModNumber" field in maintained in each table. Every time any change is made to the table, the modNumber is incremented. Then when it's time to sychronize, it can be determined which records have to be updated.
>>>
>>>My problem is in the maintenance of the modNumber field.
>>>
>>>In each table, i have the record validation rule as:
>>>newModNumber(cThisTablename,cThisModNumberField)
>>>
>>>newModNumber is a stored procedure, as follows:
>>>
>>>
FUNCTION NewModNumber
>>>
>>>LPARAMETERS tcTable, tcField
>>>
>>>LOCAL liModNumber
>>>
>>>liModNumber = AssignModNumber( tcTable, tcField )
>>>REPLACE ( tcField ) WITH liModNumber IN ( tcTable )
>>>
>>>RETURN .T.
>>>** End NewModNumber
>>>
>>>I am getting the error "Illegal recursion in rule evaluation" when the REPLACE statement is executed.
>>>
>>>The AssignModNumber Function is:
>>>
>>>
***********************************
>>>** from Craig Berntson's Knowledgebase - 8/24/99
>>>** used to generate ModNumbers
>>>FUNCTION AssignModNumber
>>>
>>>LPARAMETERS tcTable, tcField
>>>
>>>LOCAL lnArea, liModNumber
>>>
>>>* Save current work area
>>>lnArea = SELECT()
>>>
>>>IF !USED("GeneratePK")
>>>  USE sagenpk IN 0 SHARED ALIAS GeneratePK
>>>ENDIF
>>>SELECT GeneratePK
>>>SET ORDER TO TAG GPK_PK
>>>
>>>* FLOCK seems to work a bit better than RLOCK.
>>>* I've never had a problem with it
>>>DO WHILE !FLOCK()
>>>ENDDO
>>>
>>>SEEK UPPER(tcTable)
>>>IF FOUND()
>>>  REPLACE gpk_CurrentModNumber WITH gpk_CurrentModNumber + 1
>>>  liModNumber = gpk_CurrentModNumber
>>>ELSE
>>>  INSERT INTO GeneratePK ( GPK_PK, gpk_CurrentNumber, gpk_CurrentModNumber ) ;
>>>    VALUES ( UPPER( tcTable ), 0, 1 )
>>>  liModNumber = 1
>>>ENDIF
>>>
>>>FLUSH
>>>UNLOCK
>>>
>>>SELECT (lnArea)
>>>RETURN liModNumber
>>>** End AssignModNumber
>>>
>>>
>>>I am using views. The VIEW doesn't have a row rule, but I THINK what might be happening is that the rule is somehow being called twice (yes, recursion....) perhaps once for the table and once for the rule? When i update the table directly, in a browse, the modNumber is incremented properly.
>>>
>>>Once i get the "Illegal recursion in rule evaluation" my only options are CANCEL and HELP. I choose CANCEL, and a PROCEDURE CANCELLED message appears. I click on OK and i'm back in the NewModNumber procedure again...on the line before the REPLACE.
>>>
>>>Any insight or help is appreciated! TIA, j
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform