Hey Jack:

I think we're on the same page. I would never advocate that front-end editing be abandoned in favor of ONLY bouncing errors back from the server, but I would rather have redundant checks, and an occasional bounce, than allow data in that breaks a business rule. I've seen what happens with DBs created by developers who don't like constraints, or even foreign keys, because they "interfere with flexibility." (No, I don't think you would ever do this.)

Let me clarify the "upper case collation". Bad choice of words on my part. Every time I get in a hurry I lose precision. I assumed (possibly in error) that the order numbers coming in are validated against an orders table. Using a case-sensitive collation would make the lower-case 'cqs' strings fail. (Of course, it might also cause unexpected duplicates, depending on how the applications are written.)

The point was and is, if keeping those lower case values out is critical, steps can and should be taken to prevent it at the db level. Even if it's only changing the insert procedure to store UPPER(custOrderNo) instead of custOrderNo. In this case, it sounds as if it were more of an annoyance than a show-stopper.

Regards,

Bob