Not sure if this is a bug or not.
I was trying to build a browse routine using action scripting to prompt the user for parameters at run time. I selected the browse and then selected "Prompt for parameters at run time." When I went to add the filter condition, the fields I was shown were from a different table - not the one associated with the browse. Restarted Action scripting a number of times, always with the same result when it came to the filter.
I deleted the browse, compacted the database, rebuilt indexes etc., exited Alpha 5 and then retsarted and recreated the browse with the same browse name (DateBrowse). Tried action scripting the process again with the same results.
Next I dropped the incorrect appearing table from the database and went through the script process again. This time I was presented with fields from another incorrect table.
In both cases the incorrect table that appeared in the filter building routine was the first table (alphabetically) in the database. The browse name was also the first one (alphabetically) in the database.
I renamed the problem browse so that it would appear later in the browse list and was able to build the script without any problems. The fields that appeared in the filter routine were from the correct table.
Soooo, just for the heck of it, I tried to use action scripting to build an open browse routine on what is now the first browse (alphabetically) in the database and guess what? The fields in the filter building routine are from the wrong table - they are again from the first table (alphabetically) in the database. Unless there is something at work here that I'm not aware of it would seem this might be a bug.
I not sure how clear this explanation is but, in simplest terms, if there are a number of tables and browses and I try to use action scripting to build an "Open Browse" routine with runtime filtering criteria, if the browse is the first one alphabetically in the database the filter building routine will show fields from the first table alphabetically in the database.
I was trying to build a browse routine using action scripting to prompt the user for parameters at run time. I selected the browse and then selected "Prompt for parameters at run time." When I went to add the filter condition, the fields I was shown were from a different table - not the one associated with the browse. Restarted Action scripting a number of times, always with the same result when it came to the filter.
I deleted the browse, compacted the database, rebuilt indexes etc., exited Alpha 5 and then retsarted and recreated the browse with the same browse name (DateBrowse). Tried action scripting the process again with the same results.
Next I dropped the incorrect appearing table from the database and went through the script process again. This time I was presented with fields from another incorrect table.
In both cases the incorrect table that appeared in the filter building routine was the first table (alphabetically) in the database. The browse name was also the first one (alphabetically) in the database.
I renamed the problem browse so that it would appear later in the browse list and was able to build the script without any problems. The fields that appeared in the filter routine were from the correct table.
Soooo, just for the heck of it, I tried to use action scripting to build an open browse routine on what is now the first browse (alphabetically) in the database and guess what? The fields in the filter building routine are from the wrong table - they are again from the first table (alphabetically) in the database. Unless there is something at work here that I'm not aware of it would seem this might be a bug.
I not sure how clear this explanation is but, in simplest terms, if there are a number of tables and browses and I try to use action scripting to build an "Open Browse" routine with runtime filtering criteria, if the browse is the first one alphabetically in the database the filter building routine will show fields from the first table alphabetically in the database.
Comment