LingoJango Posted March 22, 2008 Share Posted March 22, 2008 Evaluate ( "ProjectIntDailyApptsDay1::_c_CommonOne" ) evaluates just fine. Evaluate ( "ProjectIntDailyApptsDay" & $InterpreterDay & "::_c_CommonOne" ) does not evaluate where $InterpreterDay = 1 Can anyone tell me what I'm missing here? I'm feeling really stupid, and expecting to feel even stupider when someone comes up with an explanation. Data Viewer says "The specified field cannot be found", and highlights the text Evaluate ( "ProjectIntDai but I just don't get it. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 Hey LingoJango try GetField ( "ProjectIntDailyApptsDay" & $InterpreterDay & "::_c_CommonOne" ) either inside or outside of the Evaluate. Maarten PS you are using this in a script? otherwise $$interpreterday. Must say I never used getfield and a script variable, but see no reason why not. checking.... Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Hey Maarten, I did try GetField, same result only no text gets highlighted in the formula. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 I'm trying to reproduce this. Making a sample. You are trying to retrieve values from different TO's and the $variable is the switch right? Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Yep, that's right. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 in my setup both evaluate and getfield work. What I did: a parent table and two TOs from the same child table. Relationship defined as Parent::Switch >-----<:parentid> If I put a number value in Parent::Switch that occurs in Child::ParentID, then the script set variable [ $var ; parent::Switch ] Show Custom Dialog [ "peek ; "Switch = " & $var & ¶ & "Getfield: " & GetField ( "child" & $var & "::ChildContent" ) & ¶ & "Evaluate: " & Evalueren ( "child" & $var & "::ChildContent" ) ] returns the content of the first related field on both counts. It's a bit lame, you could achieve the same result with just one TO... I'm not sure I understand the purpose. Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Hey, Maarten. Thanks for the sample. The purpose of using Evaluate is as an If condition in a script, to test whether related records exist, and I can certainly think of clumsy workarounds, but ultimately the problem is the calc itself. I'm still stumped as to why my calc isn't working. Other than length, I can see no functional difference between your Evaluate ( "child" & $var & "::ChildContent" ) and my Evaluate ( "ProjectIntDailyApptsDay" & $InterpreterDay & "::_c_CommonOne" ) I can shorten the variable name, but shortening the table names is going to wreak havoc with the naming scheme. I'm testing this in my db and Evaluate *seems* to work for some shorter TO names. FM really ought to warn us in Help if the length of Evaluate expressions is *that* limited... but I've seen lengthy examples in books. I really don't get it. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 I can shorten the variable name, but shortening the table names is going to wreak havoc with the naming scheme. I'm not aware of any limits. Try EvaluationError ( Evaluate ( #your statement# ) ) and see which error number crops up. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 TO names are limited to 100 chars. Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 106 - table is missing. But it isn't! I've added a Let which for some reason seems to work, i.e. it produces an accurate result even though testing it in Data Viewer gives an error. Is this database corruption? Oh, dread! Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 - can you view the data using a hardcoded relationship? - check data type consistency If you like I can take a look at the file. contact me offline. Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Yes, I can view the data, and it is consistent. I'm on it. Quote Link to comment Share on other sites More sharing options...
AHunter3 Posted March 22, 2008 Share Posted March 22, 2008 Evaluate ( "ProjectIntDailyApptsDay1::_c_CommonOne" ) evaluates just fine. Evaluate ( "ProjectIntDailyApptsDay" & $InterpreterDay & "::_c_CommonOne" ) does not evaluate where $InterpreterDay = 1 Can anyone tell me what I'm missing here? I think so. Evaluate is very very very literal-minded, and you can get mired in quotation-mark backslash-escapeland if you try to evalute a string that already necessarily contains literals. Try Let ($EntireString = "ProjectIntDailyApptsDay" & $InterpreterDay & "::_c_CommonOne"; Evaluate ("$EntireString")) (there is a way to do it with \"" escapes but I hate mucking with them) Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Thanks! that fixed it! Any reason you used $ for calc variables? Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 I'm starting to suspect the value of $InterpreterDay. You say that it works for some but not all records. So could it be that on some cases, $interpreterday holds a hidden character such as ¶ or a space? to the best of my knowledge script variables have no fixed data type. Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Fixed the Evaluate calc but not the script. At this point, half of the script seems to "see" the $InterpreterDay variable properly whereas the other half doesn't. $InterpreterDay displays as the proper number in Data Viewer, but stepping through the script skips over the contents of If [$InterpreterDay = 1] (or 2 or 3...). I've tried $InterpreterDay = "1" in case it was a matter of script parameters being text strings, but that doesn't seem to be it. Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 You were right! It was the calc in the button-set parameters, which added a space that I couldn't select and see in data viewer. Whew. For a moment there I thought I'd have to go back a few backups - without even knowing how many. At least I have them... Thanks, Maarten, thanks, Allan. Quote Link to comment Share on other sites More sharing options...
Maarten Witberg Posted March 22, 2008 Share Posted March 22, 2008 $InterpreterDay displays as the proper number in Data Viewer But it's hard to see spaces in the DV and ¶ are ignored. You can force to number: GetAsNumber ( $interpreterday ) How is this variable set? Edit: Oh I see you've got it fixed. Glad to hear it! Maarten Quote Link to comment Share on other sites More sharing options...
CobaltSky Posted March 22, 2008 Share Posted March 22, 2008 But it's hard to see spaces in the DV and ¶ are ignored. Yes. FWIW, should anyone strike a situation like this again, the first diagnostic technique I would suggest is removing the enclosing Evaluate( ) function so you can seeing what string is returned by the enclosed expression. When there's an errant space or carriage return fouling up proceedings, it then becomes a *lot* easier to spot. smiley-wink Quote Link to comment Share on other sites More sharing options...
LingoJango Posted March 22, 2008 Author Share Posted March 22, 2008 Thanks, Ray. I actually had tested that - but I did it at a stage where quoting within Evaluate was part of the problem, too, and using trigger method with a parameter calc that failed to produce the guilty space. Quote Link to comment Share on other sites More sharing options...
By Soliant Consulting,
By Soliant Consulting,
By Soliant Consulting,
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.