Set Field in Find Mode Fails with no error

[James Gill]

I have a script that I am using to control finds that users are performing but for some reason the 'Set Field' script step is failing with no error.  The user selects their search criteria in a set of global fields and then clicks 'Search'.  The script then takes the information they've added to the global field and, while in Find Mode, uses the calculated result of the global field to set the actual field for the find.

This script has worked fine in the past, however now I am attempting to Find records in a related table and the 'Set Field' script step is not taking the value from the Global field into the related field.  The find works if I manually enter the data.

 

Is there some limitation that I'm not familiar with that prevents a script from setting the field of a related table while in Find Mode?

[James Gill]

Found the issue: The Global field is set up as a text field to allow ranged date searches.  The field I was searching was a Date field.  The data type has to be the same (at least for Date fields) in order for the Set Field Script Step to function.

[comment]

The data type has to be the same (at least for Date fields) in order for the Set Field Script Step to function.

 

No, not really. You definitely can set a date field to a text value. In fact, you have to set a date field to a text value in Find mode, if you want to use any of the find operators, e.g. ">" or "*".

[James Gill]

The caveat being 'In Find Mode'.  Because of the way that the Find Function works in the solution I'm working on, users perform a "Search" while still in browse mode and then the Scripting takes care of the actual find.  The problem is that the Global field the users are entering the search criteria on have to be set to 'Text' as if they are set to 'Date', as a ranged search i.e. 1/1/2014...2/1/2014 isn't a valid date when in browse mode.  The script then uses the Set Field script step to take the text-entry and places it into a date field as a find criteria.  This is where the script is failing, as for some reason the ranged criteria is not considered a Date and the values are not passed (at least that's what I assume is happening, since there's no script error it makes it a little tough to debug.

 

What's odd is that this is working just peachy on some other Date fields that are accepting text inputs.  The only difference is that this particular Date field is coming from a related record whereas the other fields are part of the table the layout is on.

 

Edit: The heck, now it's working fine.  I really wish I knew why it wasn't working before...

[Lee Smith]

I use the tools available in Advance. i.e. Script Bugger and Data Viewer in order to watch what the Script is doing.

[comment]

The caveat being 'In Find Mode'. 

 

No, it works in Browse mode, too.  Sort of. That is,  you're going to end up with ? as the contents of the date field. But that's irrelevant to what you are describing, since you are setting the field in Find mode.

[LaRetta]

Edit: The heck, now it's working fine.  I really wish I knew why it wasn't working before...

Is there some limitation that I'm not familiar with that prevents a script from setting the field of a related table while in Find Mode?

 

Hi James,

 

It has been my experience that you can spend weeks trying to solve something and the moment you post about it, the problem will spontaneously and magically disappear, even before you receive a response in many cases; happens to me all the time.  ;-)

 

Searching a related table can trick you into thinking this works sometimes but not other times.  If you perform a find on a parent record then parent records will be returned if that parent has at least one related record within your search criteria.  So does your find return parent records?  Are you viewing the related results in a related field or are you displaying a portal?

 

If your related table has multiple records (some with older dates and some within the date range you seek), and you perform your find on the parent AND if you end up with a found set of parent records then it means this parent most likely has at least ONE child record within that date range but only the first child record displays in the field.  This can lead folks to believe the find failed.  On other parent records, it might display the right date (because it had no child records with older dates).  

 

When you place a related field (the many side) on a parent table (the one side), only the first related record according to the relational sort (usually natural creation order) shows in the field.  You will only know whether the find worked by placing a portal on the parent layout and seeing if any of the related records fall within the date range you specified.  The fact that you did not receive an error adds support to this possibility on why it failed for you and why sometimes it worked and sometimes not (possibly).

 

This may not be your case but it bites folks quite often.

[LaRetta]

The user selects their search criteria in a set of global fields and then clicks 'Search'.  The script then takes the information they've added to the global field and, while in Find Mode, uses the calculated result of the global field to set the actual field for the find.

 

It would also be beneficial to see what this 'calculated result' produces.  Step through the script in debugger and when it sets the related field, copy/paste the value here, please.

 

1/1/2014...2/1/2014  

 

Still, if this calculated result failed, you would get an error.  If my prior post misses the mark, please attach a copy of your script.  

[James Gill]

I use the tools available in Advance. i.e. Script Bugger and Data Viewer in order to watch what the Script is doing.

 

How people even debug without Script Debugger and/or Data Viewer is a mystery to me.

 

Hi James,

 

If your related table has multiple records (some with older dates and some within the date range you seek), and you perform your find on the parent AND if you end up with a found set of parent records then it means this parent most likely has at least ONE child record within that date range but only the first child record displays in the field.  This can lead folks to believe the find failed.  On other parent records, it might display the right date (because it had no child records with older dates).  

 

When you place a related field (the many side) on a parent table (the one side), only the first related record according to the relational sort (usually natural creation order) shows in the field.  You will only know whether the find worked by placing a portal on the parent layout and seeing if any of the related records fall within the date range you specified.  The fact that you did not receive an error adds support to this possibility on why it failed for you and why sometimes it worked and sometimes not (possibly).

 

This may not be your case but it bites folks quite often.

That's what I thought too, but when I checked the child table, there were definitely records that matched the find criteria.  On top of that, the script was returning 'No Records Found' before it magically started working *shrugs*

 

It would also be beneficial to see what this 'calculated result' produces.  Step through the script in debugger and when it sets the related field, copy/paste the value here, please.

 

1/1/2014...2/1/2014  

 

Still, if this calculated result failed, you would get an error.  If my prior post misses the mark, please attach a copy of your script.  

That's the thing...the calculated result was returning an empty value even when there was a value in the Global field that it was pasting from.  

It's working as expected now even though I didn't change anything.  On to the next problem...

[bruceR]

Pasting?