Hi,
You can not verify that you have only digits with an optional leading
minus in your field without specifying all possible lengths of the string.
I would imagine that the number of digits would not be too great...
If you enter a % in the LIKE-operation, it will mach 0-x characters of any
type, and is therefore useless for this.
I can see many other ways of doing this if you absolutely want to keep
from specifying patterns for all lengths.
One way would be to first construct the pattern in a temp-field:
FLTR1 ('Field1' != $NULL$)
Action 1: Set-Fields
tmpPattern = LEFT("[^-0-9][^0-9][^0-9][^0-9][^0-9][^0-9][^0-9][^0-9]",
LENGTH($Field1$) * 6 + 1)
FLTR2 ('Field1' LIKE 'tmpPattern')
Action 1: Message Error
You could also do something like this, I think, to strip out
non-integer-characters:
FLTR1
Action 1: Set-Fields
tmpInt = $Field1$
Action 2:
tmpChar = $tmpInt$
FLTR2 ('Field1' != 'tmpChar')
Action 1: Message Error
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Lyle,
>
>>That said, if your approach is to match the opposite and negate it, then
>> that might work.
>>If so, then you might be able to do it like this:
>
>> 'Field1' LIKE "%[^0-9]%" OR 'Field1' LIKE "[^-]%[^0-9]%"
>
> Yes, I want to match the opposite to show an error message.
>
> The suggested qualification isn't working however.
>
> The qualification 'Field1' LIKE "%[^0-9]%" OR 'Field1' LIKE "[^-]%
> [^0-9]%" works just fine to prevent users from entering alpha
> characters. Unfortunately it also prevents strings like -2222 for some
> reason...
>
> The qualification 'Field 1' LIKE "[^-]%" AND 'Field 1' LIKE "%
> [^0-9]%" is very close to what I'm looking for, but it allows input
> like -m000 for some reason.
>
> @Misi
>
> I'm don't want to use patterns, because they generate a very user
> unfriendly error messages.
>
> I'm trying to avoid specyfing all possiblities. If the wildcards work
> as documented, then it should be possible to tackle the problem
> without it.
>
> Mark
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
