Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Tricky problem
Message
 
 
À
22/03/2002 12:30:48
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Titre:
Divers
Thread ID:
00635856
Message ID:
00636144
Vues:
21
>>>>>>>>Hi everybody,
>>>>>>>>
>>>>>>>>We have the following tables:
>>>>>>>>
>>>>>>>>Methods:
>>>>>>>>MethodID MethodCode
>>>>>>>>
>>>>>>>>Messages
>>>>>>>>MessageID MethodID Message Severity
>>>>>>>>
>>>>>>>>ValCalls
>>>>>>>>ValCallID Table      Field    CallProc                  ShowFields           BldMStr(L) BldMstrP(L)
>>>>>>>>1         PropMstr            ProMstrTr(field1,field2)  Field1,Field2,Field3
>>>>>>>>2                     Owner1  Name(Owner1)              Field1,Field2
>>>>>>>>
>>>>>>>>
>>>>>>>>These are methods for table rule and fields rule. And here is the problem:
>>>>>>>>The same method could be run for the same table, but with the different combination of fields, and of course, different combination of Show Fields.
>>>>>>>>
>>>>>>>>So, the question is:
>>>>>>>>How can we identify, which particular ShowFields are associated with each error?
>>>>>>>>
>>>>>>>>The typical method's code looks like:
>>>>>>>
>>>>>>>Nadya,
>>>>>>>
>>>>>>>Am I correct in that the pcFieldName is a ShowField ?
>>>>>>>ie you are passing the FieldName to your check routine
>>>>>>>
>>>>>>>
>>>>>>>>lparameter pcValue, pcFieldName (or combination of fields)
>>>>>>>>if some error condition
>>>>>>>>   return EvalCode(MessageID, pcFieldName)
>>>>>>>>endif
>>>>>>>>
>>>>>>>>return .t.
>>>>>>>>
>>>>>>>>Can you please help me with ideas of solution for this problem...
>>>>>>>>
>>>>>>>>Thanks a lot in advance.
>>>>>>
>>>>>>Hi Gregory,
>>>>>>
>>>>>>In case of field level validations, there is no ambigiosity (ouch, spell?), but in case of table level validation we can call the same method with different parameters, e.g. for TranMstr:
>>>>>>NameRel(BUYER1,BUYER2,BUYERREL,"table")
>>>>>>NameRel(SELLER1,SELLER2,SELLERREL,"table")
>>>>>>
>>>>>>So, in this case we don't know, how to correctly identify, which record in VallCalls we would need to use in Resolve form to find the Show Fields (these are the fields, which are shown for the user to review and correct the problem).
>>>>>>
>>>>>>You see the problem now?
>>>>>>
>>>>>>Here are my ideas (thought about it at night):
>>>>>>
>>>>>>1) Include ValCallsID (or some other unique identifier) in the call of the method - this is obviously the most complicated solution, because it requires lots of changes in the existing code
>>>>>>
>>>>>>1a) Introduce new property of oValid object to hold this "ValCalls" unique identifier and assign it before each call of Table level validations - this is a little bit simpler to implement, than 1, but still requires lots of changes.
>>>>>>
>>>>>>2) In the routine, which finds ShowFields, find all records, which are relevant for the given method + given table and combine all fields together, e.g. in the above example show Buyer1, Buyer2, BuyerRel, Seller1,... etc.
>>>>>>
>>>>>>3) Put this combination of fields in ValCalls table itself, e.g. each call would have all list of fields (even if they are not relevant for this particular call).
>>>>>>
>>>>>>What do you think?
>>>>>
>>>>>Nadya,
>>>>>
>>>>>How is it driven ?
>>>>>
>>>>>(1) Table Rules are hard coded (eg NameRel(buy1, buy2, buy3) and NameRel(Sel1, sel2, sel3) )
>>>>>
>>>>>(2) The table rule goes through the table and calls CallProc with the parameters, ie evaluates(CallProc) where Table=TableInUse
>>>>>
>>>>>(3) When the database is opened, an object scheme is built, and held in memory. The TableRules parse the object hierarchy and execute the calls
>>>>>
>>>>>(4) ...
>>>>
>>>>Hi Gregory,
>>>>
>>>>We're using VFP databases. In the Table rule we have TranMstrTr("TranMstr")
>>>>
>>>>TranMstrTr has this code (schematic):
>>>>lparameter tablename
>>>>RetVal = NameRel(buyer1,buyer2,..,tablename)
>>>>if not RetVal and not oValid.bbatch && Not a Batch Mode
>>>> return .f.
>>>>endif
>>>>
>>>>RetVal = NameRel(seller1,seller2,..,tablename)
>>>>etc.
>>>>
>>>>The code, which validates the whole database, looks like:
>>>>scan
>>>>  scatter memvar memo
>>>>  gather memvar memo && Validation fires
>>>>endscan
>>>>
>>>>NameRel will call EvalCode function in case of error. This function logs the error with its details in the ValLog table...
>>>
>>>Nadya,
>>>
>>>One more question
>>>
>>>What are the record contents of ValCalls for TranMstr ?
>>>
>>>ValCallId, Table, Field, CallProc, ShowFields
>>
>>Hi Gregory,
>>
>>It would be easy to me just send you the table, if you'd like. I put the content in a file, (list stru to file, list to file), but the file is hard to put here in UT.
>>
>>BTW, ValCalls doesn't have unique identifier, as I just checked it.
>>
>>Anyway, here is one record content for TranMstr
>>
>>Table       Field    IMethodID  CallProc      ShowFields         Bld   BldP
>>
>>TranMstr             120       NameSrce(Source,; Buyer1,Seller1   .t.   .f.
>>                               buyer1,"table")
>>
>>It has couple of such records for table level (all them are marked InActive), since the only one method, which we call, is TranMstrTr (it in turn invokes all other methods...)
>>
>>I'm afraid, I confuse you...
>
>Nadya,
>
>Can you put in my email
> (1)zip the table ValCalls
> (2) source code of NameRel
> (3) source of another table CallProc
>
>Where do you want to know the ShowFields ? Is it in EvalCode() ?

Hi Gregory,

I'm sending you the zip with Validate database. The ShowFields we need to know in another form, called resolve form.
If it's not broken, fix it until it is.


My Blog
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform