Hi Guys:
I’d like to know how to handle unique field validation in Servoy. Can I use a Database contraint? How do I handle this in Servoy?
Also, once a field is setup, is it not possibe to uncheck, “Allow Nulls”, or to setup alternate Keys?
Will a PK or alternate Key automatically be set to do a unique check?
Thanks,
Lee Snover
Hi Lee,
It’s best to enforce the validation within the solution.
You cannot uncheck the allow nulls nor change the name of a column in the Servoy Dataproviders Editor by design. This is because your backend database might be used by other interfaces that rely on column names and/or the not null setting. You CAN do this in the backend using other tools - then re-launch Servoy and it will reflect the changed settings.
A PK will be checked for uniqueness, a FK will not.
Hope this helps.
bcusick:
Hi Lee,It’s best to enforce the validation within the solution.
You cannot uncheck the allow nulls nor change the name of a column in the Servoy Dataproviders Editor by design. This is because your backend database might be used by other interfaces that rely on column names and/or the not null setting. You CAN do this in the backend using other tools - then re-launch Servoy and it will reflect the changed settings.
A PK will be checked for uniqueness, a FK will not.
Hope this helps.
Bob:
Gotcha, so the Null check is based on the backend properties, not exclusive to Servoy.
Whats the recommended way of enforcing uniqueness with the solution? What are the ramifications of doing this in the backend as well? I like to cover every avenue on these issues.
Thanks,
Lee
Lee,
Not sure what exactly your validation issues are, but I have it laced throughout my solution. With my solution data is validated throughout its cycle ex: the ‘order’ starts in receiving and ends as a invoice.
Each department edits and adds specific data that is validated when a particular step within work flow has been completed. the order then goes to the next queue (dept).
I use allot of “if” agruments to validate field contents or record status. If a condition is not met then the order (form) cannot be completed / closed / forwarded.
When someone tries to submit the order, if a field (estimate date) is empty (null), then a dialog pops up and focus is gained on the field, something along those lines.
I am not sure what type of validation you are talking about, but I enforce validation throughout the front end during workflow. Is is is done correctly , invalid data show not make it to the back end.
Hope this helps,
Erich
ebrandt:
Lee,Not sure what exactly your validation issues are, but I have it laced throughout my solution. With my solution data is validated throughout its cycle ex: the ‘order’ starts in receiving and ends as a invoice.
Each department edits and adds specific data that is validated when a particular step within work flow has been completed. the order then goes to the next queue (dept).
I use allot of “if” agruments to validate field contents or record status. If a condition is not met then the order (form) cannot be completed / closed / forwarded.
When someone tries to submit the order, if a field (estimate date) is empty (null), then a dialog pops up and focus is gained on the field, something along those lines.
I am not sure what type of validation you are talking about, but I enforce validation throughout the front end during workflow. Is is is done correctly , invalid data show not make it to the back end.
Hope this helps,
Erich
Erich:
I understand this concept and it is essential. However, enforcement of key validation should also be employed on the backend. The reason being, Servoy may not be the only access method, and someone could slip something it that violates a key rule, such as uniqueness. I think a good app. will not be either/or, it will be a blend of both.
Regards,
Lee Snover
lee,
I agree with you completely, all PKs should be controlled by the backend. I thought you where refering to validating the data on a field basis. I am fortunate to be building a solution that will be the only front end writing data to the backend, therfore there is less to consider when evaluating conflicts.
Lee,
Sorry if I wasn’t clear - you CAN specify uniqueness in the backend. If you try to violate that uniqueness - then the JDBC driver will throw an error.