Field validation expression.

[bnstaylor]

Would appreciate if anyone has an answer on this:

If a field in a table has a validation expression against it and you want to change that validation, does that mean a schema change and hence all programs have to be recompiled?

Nasty and time consuming if so …. L

I cannot test this as I do not have access to be able to change the DB and/or add records direct to the DB.

Thx, Barry.

 

[doreynie]

Don't know this by heart, but can't you try to setup a local database and try it there?

 

[bnstaylor]

Don't know this by heart, but can't you try to setup a local database and try it there?

Thanks for that.

I created a table with two fields, one of which I set with a validation expression of "Lookup (cu-freq,"N,W,F,M,Q") > 0".

I then created a record with a "cu-freq = 'x'".

At this point I am confused with what the validation expression is suppoed to do? Apart from my wanting to change the validation expression to include other valid charcaters, such as "x", and not have to recompile all programs that access this particular table, what is its purpose in life?

Am I incorrect in the belief that Progress would not allow any character to be entered into this field that did not pass the validation rule?



Regards, Barry.

 

[TomBascom]

Validation expressions have no usefulness in modern code. They apply too late in the data entry cycle to be useful (validations are performed just before data is written to the db). Don't use them. You're on the wrong path.

If you do use them your assumption about changing them and having the change picked up by code without recompiling is wrong -- if you change a validation expression (or a format, a label or a help message) that change isn't noticed by code until you recompile (which is why it doesn't count as db CRC change).

Dictionary validation expressions made good demos back in the day but have never really been useful for real code. IMHO the capability should be deprecated and removed from the standard dictionary code -- and it could be dropped from the language without a tear being shed on my part too.

 

[bnstaylor]

Validation expressions have no usefulness in modern code. They apply too late in the data entry cycle to be useful (validations are performed just before data is written to the db). Don't use them. You're on the wrong path.

If you do use them your assumption about changing them and having the change picked up by code without recompiling is wrong -- if you change a validation expression (or a format, a label or a help message) that change isn't noticed by code until you recompile (which is why it doesn't count as db CRC change).

Dictionary validation expressions made good demos back in the day but have never really been useful for real code. IMHO the capability should be deprecated and removed from the standard dictionary code -- and it could be dropped from the language without a tear being shed on my part too.

===================================================

Tom,

thanks for that.

Understand and am in agreement with you on what you have stated above.

However, just to explain myself a bit further, in my case I do not necessarily want to amend the validation expression on the current schema. What I want to do however, is to populate a field which has a validation expression on it with different values other than those in those in its current expression. The field is on the customer master and we want to place new values in it other than those values currently stated on the validation expression. As you could imagine the table is used virtually everywhere within the system.

My original question (thinking that the expression had to be true for the field to be populated) was concerning how to amend the expression without re-compiling everything? But when I did a test by creating a test DB, I found I could create a record with the field populated other than what is stated in the validation expression. This last bit puzzled me!

So, and please correct me if my understanding is incorrect on this, if I want to populate a field with different values to those held in its validation expression, I can do so without having to change the expression? Not having to change the expression then means I do not have to re-compile programs using that table?

Appreciate your time.

Regards, Barry.

 

[TomBascom]

That's another thing about validation expressions... like FORMAT, LABEL and help messages in the dictionary they only apply by default (you can over-ride them locally) and only to UI verbs (like UPDATE).

Take the sports2000 db for example. It has a validation expression on custNum requiring custNum > 0. So:

find first customer exclusive-lock.
update custNum format "->>>9".

Gives you a validation error if you enter a negative custNum such as -1. (The default FORMAT is also an attempt to prevent negative values but, as you see, I over-rode that...)

You can easily over-ride the dictionary validation in code like so:

find first customer exclusive-lock.
update custNum format "->>>9" validate( true, "" ).

And you can programmatically assign any old value to the field without validation:

find first customer exclusive-lock.
custNum = -9999.

Changing the schema's validation phrase does not affect the CRC and thus does not force a re-compile -- but why would you want to leverage that? Keeping track of which r-code has been compiled with which version of the validation phrase would be really ugly and is bound to blow up sooner or later. If you need to use validation (in spite of its pitfalls) and you need a different expression in some bit of code then use the local VALIDATE() phrase.

 

[it@flude.co.uk]

When we use the dictionary validation, we refer to an include file. That way, we can change it while people are logged in and using the system. But, generally, we rarely use it for the reasons above.

 

[bnstaylor]

To all of those who have enhanced my knowledge on validation expressions, I thank you.

I try to learn somehting new every day.

Regards, Barry.

 

[tamhas]

When we use the dictionary validation, we refer to an include file. That way, we can change it while people are logged in and using the system.

Changes to the include file will not be noticed by any compiled code. If these changes are being noticed, then you are running uncompiled code.