This works in much lower versions than 11.
Both approaches should work but Get ( FileName ) is the better option. I'd check to make sure that the text in quotes exactly matches the name of your value list.
And is your check box field a field of type text?
Yes, my checkbox is of type Text. It's just checking one check box instead of checking all the checkboxes.
to repeat: I'd check to make sure that the text in quotes exactly matches the name of your value list.
and make sure that this is the correct value list.
And make sure that nothing else is modifying it--such as another script tripped by a script trigger or an auto-enter calculation.
You may find it helpful to make a copy of this check box field and format it as an edit box so that you can inspect that actual data put in the field by your script.
I did checked everything, and there's no auto-enter for this field and no script trigger associated with this field. And I also did a copy of the field as a edit box to check if it is actually catching the correct value and it does, it just won't select all the check box once the button is clicked. It only selects one record instead of selecting all checkboxes.
And I also did a copy of the field as a edit box to check if it is actually catching the correct value and it does, it just won't select all the check box once the button is clicked.
Sorry, but those two statements appear to contradict each other.
If you have a value list defined with say these values; Apple, Orange, Peach
Your script step should change the data in the edit box to be:
And the copy formatted with check boxes will show all three boxes selected.
So either you are not seeing all listed values in your edit box copy, or the value list specified for the check boxes lists different values from a different value list.
It only selects one record instead of selecting all checkboxes.
I hope that the term "record" in that sentence is a typo as so far, we have only discussed the values to be found in a single field of a single record...
Hmmm, could your set of checkboxes possibly be a set of individual fields with just one check box each? Instead of one field with multiple checkboxes?
Yes, you were right about the size of the edit box (format copy of the checkbox). If I may start it again, what our sales manager to happen is if and when he selects the button, all the "Approved" checkboxes for the entire record will be selected (value for the value list for this are "Approved" and "Disapproved") but still can unselect or deselect the checkboxes one at a time.
It's really confusing for me on how to do this.
Sounds like you need a script patterned after this example:
Set Field [YourTable::FirstCheckboxField ; "Approved" ]
Set FIeld [YOurTable::SecondCheckboxField ; "Approved" ]
and so forth with one set field step for each such field.
Thanks Phil! But now how can I do this for all a found set of records let's say 100,000 records and when the button is clicked same thing will happen ("Approved" will be selected) through the entire found set?
The need to do that suggests that you may not have the best possible design for your database, but Replace field Contents can be used in place of each Set Field step to update that field to be "approved" for each record in your found set.
Thanks again Phil! It's just really hard for me to convince some of the people in my work place, so most of the time I end up re-writing or re-designing the database just to give the what they want and the way they want it. Thanks again Phil!
Yet what I am thinking of wouldn't necessarily change the look and feel of the layouts nor their visible function, but would make for a much more flexible faster, and easier to maintain design...
Having multiple fields that all store the same type of data such as "approved" suggests that it might be better to replace the multiple fields with multiple related records with just one field in that record inplace of all the individual fields. An invisible portal can be used to display such data and the user is none the wiser but your scripts to work with the data get much simpler with and making needed changes to the list of such approval fields also becomes easier.
Needing to update large blocks of records all at once suggests the possibility that you shouldn't have this field in large numbers of individiual records in the first place. If the records are all common to a particular group, a relationship linking them to a single record that represents that group might be in order with that field now located in that single record instead of multiple copies in your current table. The user doesn't necessarily know that this additional table/record even eixists, but now updating the fields can be a case of changing one field in one record instead of thousands and thus they are pleased fo find that it works many times faster.
But these are just basic generalizations based on very little information so they may not be applicable to your database.