I have a formtype with single field: collection, containing unspecified number of anonymous selects. Is there a way to check if there are duplicate choices using builtin constraints? In case I have to write constraint myself, there is another problem. If I add the constraint on parent, how can I add error to child on specific index? If I add the constraint on children using All - how can I access values of other children?
Selects are allowed to return null value. The form is not bound to entity.
Thank you.
Ok, after digging through 10 pages of Google and SO results, I didn't find anything. So, I dug further, and as often happens, I've found solution in unit tests - symfony github link to this specific thing which solved my problem.
Now when I want to add error to specific field in collection, I can do:
$this->context->addViolationAt('['.$i.']', 'Error in field %d', $i);
This is case for unnamed collection children with default numeric indexes, I didn't test it with named ones. Also - remember about collection having error_bubbling enabled by default.
Related
I created a custom work item type (WIT) and I added a field of type integer for usage as unique identifier. It is called ID and is a required field.
I would like the following constraint:
When a user creates a new work item of this type and inserts a value for ID, a check is run to verify that there is no work item of this type that already has the same ID. If so the user should be prevented from creating the work item.
The point is to avoid having multiple work items of this type with duplicate unique IDs. I looked into the "Rules" section to see if I could add a constraint to check for pre-existing integers of the same value, and prevent the user from creating the WIT if it already exists in the system. However I was not able to find a way to do so. I also tried making the field of type identifier but that just forces you to user a person (not number) as an identifier.
Your goals are not clear in your question. You already have ID (or System.Id as system reference) for each work item type. You do not need to create something new. Rules in work items types do not support complex logic (Sample custom rule scenarios).
As a workaround (if you need the second id for your work item type), you can:
Set default value 0 for your field.
Create a custom app to:
Find 0 ids: Query By Wiql.
Updated them to the calculated value: Work Items - Update.
I have a multi-column pulldown combo box (cmb_users) that lists user names on a form (frm_myusers), the data is straight from a table called "dbo.my_users", primary key "pc_user_id", and it is the first column in the pulldown.
I then have a multi-form sub-form embedded into the parent form (frm_myusers) that contain one or more roles for each user. The data source is straight from a table called "dbo.my_users_roles" its primary key is pc_user_id. The relationship between dbo.my_users and dbo.my_users_roles is 1 to many.
The challenge I am having is When I try to bind the combobox to the sub-form I get the "cannot bind to an unbound form error"
So then I tried passing the combobox values to a query (qry_my_users_roles)behind the scenes to drive the sub-form. The criteria for the query was on pc_user_id as =[Forms]![frm_users]!cmb_users.Column(0), and I get the error below. Not sure where to go from here.
Ultimately is there a way to simply bind a pulldown to a sub-form without the need to jump through hoops passing variables to queries and refreshing? Mapping fields to query criteria can be quite cumbersome of the spelling or syntax is not absolutely perfect :(
Thanks in advance.
As the combobox is unbound, add it to the master fields:
sci_cnt_id;NameOfCombobox
and adjust the child fields as well:
sci_cnt_id;sci_own_id
Should you wish to show all records, you must maintain the field count, so use:
sci_cnt_id;sci_cnt_id
I have a form based on a multiple-tables query. As some fields from different tables have the same names, I must add the corresponding table's name. However, there are hyphens in the tables' names as well as in the fields' names (both inherited from foreign Excel tables).
In VBA there is no problem: [Table-1.Field-1] always works well (also in SQL queries). However, when I write this in drafting mode as data source into the form, Access "thinks" this would be wrong and replaces it automatically with [[Table-1].[Field-1]] - with the result that the form then displays the error #Name?. I tried to replace [] by quotes but without any success.
Note that there is no error when only the table or only the field has a hyphen: both MyTable.[Field-1] and [Table-1].Myfield are accepted by the form.
The correct syntax should be:
[Table-1].[Field-1]
Or, using bang notation:
[Table-1]![Field-1]
Meanwhile I found not a true answer, but nevertheless a quite satisfactory workaround by adding following calculated field into the query:
MyWorkAround: [Table-1.Field-1]
Then I can simply refer to [MyWorkAround] in the corresponding form's field to avoid the form's bug. But this isn't really very elegant !
Note that I always use [ … ] around fields, even where not necessary. This practice helps avoiding a lot of errors.
I have a table called transactions. Within that is a field called ipn_type. I would like to create separate table occurrences for the different ipn types I may have.
For example, one value for ipn_type is "dispute". In the past I would create a global field called "rel_dispute" and I would populate that with the value of "dispute". Then I could create a new table occurrence of the transactions table, and make a relationship based on transactions::ipn_type = transactions::rel_dispute. This way only the dispute records would show up in my new table occurrence.
Not long ago, somebody pointed out to me that this is no longer necessary, and there is a simpler way to setup such a relationship to create a new table occurrence. I can't for the life of me remember how that was done, though.
Any information on this would be greatly appreciated. Thanks!
To show a found set of only one type, you must either perform a find or use the Go to Related Record script step to show only related records. What you describe as your previous setup fits the latter.
The simpler way is to perform a find - either on demand, or by a script triggered OnLayoutEnter.
The new 'easy' way is probably:
using one base relationship only and
filtering only the displaying portal by type. This can be done with a global field, a global variable containing current display type. Multiple portals with different filter conditions are possible as well.
~jens
I have a drop down list of subjects. Two particular subjects are Mathematics and Additional Mathematics. When I choose Mathematics from the drop down list, records from Additional Mathematics and Mathematics are both displayed. Worse is that records from Additional Mathematics are shown first. Many colleagues made mistakes because of this.
How do I make the drop down list such that when clicked, the exact terms are used instead?
This is a problem that is not necessarily unique to FileMaker. You are searching for a name that is imprecise because it is a match for multiple names. Rather instead you might want to search for a unique key whose subject name is 'Mathematics' as displayed in your drop down. It is the use of that unique key that allows you to perform a precise search, even when the name of one subject is a partial or complete match for another.
This solution requires you to add a unique serial number which is, in your case, to alter the Subjects table and add a field called 'idnumber' or similar. The field type should be Number, and the options should include Auto-Enter-Serial number-Generate and On creation-increment by 1. The trick here lies in making sure no two subjects have the same 'idnumber' even when you aren't paying attention, so set the next value to something greater than the number of subjects that already exist. Then from another layout assign each existing subject a unique idnumber, noting that if there are a great many subjects you could script that step.
I should mention that many recommend a best practice of never changing a production layout, but rather to duplicate the layout and make the required changes to the duplicate. This minimizes the effects of testing your changes etc.
Finally, change your layout in inspector such that the drop down list shows Use values from field: 'idnumber'. Select Also display values from second field: 'Subject' and Show values only from second field. Now your drop down is the same clean selection as before. The field will not look correct yet because it will show a number. To make it look correct you can insert another field, selecting 'Subject'. Place that field over top of the 'idnumber' and send 'idnumber' to the back. Fill the 'Subject' field with the correct background solid color instead of none, and enjoy your new precision search capability! The entire process is handled server side so it should not matter that client access is IWP.
If you're using the selection to do a find, put an "==" before the text you're searching on. This will tell FileMaker to do an exact field contents search, instead of a "contains" search.