Thomas --

Unfortunately, your unspoken assumption doesn't fit my case. This processing actually occurs during a background job, so there is no human intervention possible. Furthermore, there's no date field in the source file that allows me to know which records may have changed, so I must re-process the entire file each time (hourly, as it turns out).

Thanks,

Jim

>James,
>
>unspoken assumptions on my side:
>routine is planned for field validation during data entry or a batch like run on data entered, but ALWAYS with a human to decide cases where automatic handling fails. That approach gets me out from under the pressure to be 110% correct and helped me a lot in defining rules for identification of duplicates for instance.
>
>Just try to get the automatic percentage above 90% (reduces manual work a lot!) and typically you can get with "easy coding" to percentages >97%. JUst get the code for "human safety net" in order and realize that this is not meant to be highly optimized code - in record validation for this field up to 100ms might be ok and on batch jobs only focus on the "human time" saved<g>.
>
>>>Then look for all occurrencces of substrings consisting only of numbers and strings with 12 numbers.
>Here I was talking on a record basis. For all examples you cited "1 12345 12345 1" is the only Subst consisting
>of 12 "number" chars and therefore not problematic.
>
>"Partno: 156 597 123 498 Big Widget 1 12345 12345 1"
>
>would be a case where human intervention is needed. Another case would be
>
>"Big Widget 1 12345 12345 1 15 23 54"
>
>but the first step is to find out how many different possible UPC codes are hidden in the string.
>As long as it is only one, take that and move on. The fringe cases will include leading zeros and
>probably other non-numeric special chars embedded in the UPC code.
>
>UPC_Code("Big Widget 1 00345 12345 1") == UPC_Code("Big Widget 1-345/12345\1") ??
>
>regards
>
>thomas