Re: ODBC was: Trigger programme without a trigger.

rob@xxxxxxxxx wrote:

Philosophy? Best tool...

Or, would you do some rudimentary error checking at the client like:
Birthdates for a new hire cannot go back into the 1500's. We only allow (M)ale, (F)emale, (U)ndetermined for sex.

Red herring alert. I always have error checking on the client. That has nothing to do with business rules. I also have full error checking - that is, repeat of EVERY client-side check - on the server. If you don't do that, you're ( in the words of Bugs Bunny) a maroon.

I suspect that you would try to handle many of these errors at the client in the belief that it might make it easier to highlight the right field on the screen, etc.

Yes, but again, red herring alert. I still need some way to highlight errors that are identified in the server, so it's no easier. It's actually extra work to do client-side validation, but we do it for performance reasons.

Now, if you are already doing this client validation, and the client is THE ONLY interface that will be updating the data, why not do all the validation there? You've got a dedicated processor just to do that (your EDI PC), it will use less bandwidth, etc.
Now, I am not advocating ODBC validation for all my files. But, in this case, it seems to make sense.

Nope. No way. For many reasons, the most important being that I can't ensure that the validation will be done. I'm sorry Rob, but I would not consider this approach. I would be interested to find out if anybody on the list would abdicate validation of production data to a program off the i. I'd be quite surprised if anyone did.

<snip>
Because I'm not exaggerating when I say I would fire anyone who did this.
</snip>
How many W2's do you file for your employees? :-)

Oh, now you forget my time at SSA ...

Joe