Using If NOT

vinsnash · Post by **vinsnash** » Fri Mar 06, 2009 1:52 pm

I've searched for this but don't seem to find exactly what I need. I have a BO 'UnitTable' that contains 'UnitCode' as an attribute. I have another BO 'NSCPers' that also contains 'UnitCode' as an attribute. I need to test that any entry of 'UnitCode' in 'NSCPers' exists in 'UnitTable'. I tried:

If NOT(EXISTS UnitTable WHERE(UnitTable.UnitCode = THIS NSCPers.UnitCode)) THEN REPORT ERROR '....'

It didn't seem to like 'THIS NSCPers' as 'not found' object. Can someone show me the correct syntax for what I tried to do? I need to document the correct way to make the validation for a proposal.

Thanks

tford · Post by **tford** » Fri Mar 06, 2009 4:41 pm

Have you tried:

If NOT(EXISTS UnitTable WHERE(UnitTable.UnitCode = NSCPers.UnitCode)) THEN REPORT ERROR '....'

vinsnash · Post by **vinsnash** » Fri Mar 06, 2009 10:36 pm

No I didn't. I was under the impression that THIS was required to specify the current instance being created or modified. There will be a lot of instances of NSCPers.UnitCode that match a UnitTable.UnitCode. Is that a problem?

Thank you for the help.

tford · Post by **tford** » Sat Mar 07, 2009 5:27 am

By putting this rule in NSCPers BO, it will fire when ONE individual instance of NSCPers is being added or modified. So, there is no need to have the THIS. The ONE instance being added or modified is that one that is in context for the rule firing.

technopak · Post by **technopak** » Sat Mar 07, 2009 11:55 am

Or another suggestion - why don't you set your NSCPers.UnitCode as a dropdown list referencing your UnitTable object ?

Then you can be certain that the entered NSCPers.UnitCode is valid.

vinsnash · Post by **vinsnash** » Sat Mar 07, 2009 11:59 am

That's an idea but there are over 300 of them and that would be an long list for picking from. I'm an old procedural programmer. I was hoping there would be something more in line with "READ UnitTable INVALID KEY ......

Thanks for the help

technopak · Post by **technopak** » Sat Mar 07, 2009 12:12 pm

I can empathise with the procedural outlook too

If you set the items in your dropdown list to 'Fetch records dynamically as user types' in the presentation of your referenced attribute on your form, the list won't be 300 long to choose from, but instead will display and fill the form field with only valid options as the user types.

For example, if the user types first letter C, only the codes commencing with C will be presented as options and a simple click can then complete the field entry. It's quite user friendly too compared with having to type in a complete code each time.

Might be worth looking at .....