Re: ODBC was: Trigger programme without a trigger.

Joe Pluta wrote:

No. I shouldn't have to explain this, but on the tiny chance that you actually believe this is a valid argument, I will. Regardless of all your good intention, with offline validation the server can't guarantee that the ODBC client has done its job. It opens up a whole new avenue for spoofed data, and as such is utterly indefensible.

Ah, heck, Rob, sometimes I don't know whether you're just yanking my chain or you really believe this, so I figured I'd give it a second swing. Seriously, I racked my brain but I can't think of a situation where I'd do this. I have no problem bringing in outside data - transactions from EDI, for example - but I would never punch them into my database without running them through validation. Can you give me a situation where you would use this?

I'll wager that not one person on this list would implement a system where the server doesn't validate production data.

Then I got to thinking about this particular statement and realized I may have overstepped myself. Because *technically*, anybody who does pure ODBC updates to their database is doing exactly that: implementing a system where the server does not validate the data.

Thanks for making me think this through, but this is the reason I so hate ODBC access. I don't care how good your controls are, all it takes is the client program to miss one validation, and all your hard work goes up in flames (not to mention the extra vector for malicious hacking). Now, if you have trigger programs or I/O modules that are accessed via stored procedures, that's different, but unfettered ODBC just makes my skin crawl.

Joe