>
and thats what my code does .. there no mentioning of tx so i didn't include it .. nor does it matter in this context i think ..
>

In the server arena transactions ALWAYS matter. The only exception I can think of is bulk-copy scenarios.


>i'm not posting here to educate people howto architect their applications ..
>that's their own decision .. i just answer question's to specific
>problems ..

Yes indeed, and hence my response. Your code will "work" - but it is far from optimal. Code scenarios such as this don't scale particularly well in terms of code maintence.

The bottom line is if one is going to piece together T-SQL Code on the client - one might as well just call a stored proc. Why? For one thing, a stored proc is nothing more than a function call with a set of parameters. From an OO standpoint and from a modular development standpoint - this is absolutely the best and most proper way to go.

Please understand I am critiquing your solution - not your personally. From a professional development prespective - your solution leaves alot to be desired.


>by the way i don't think the code is so terrible at all .. the new CursorAdapter Class has a property "ConflictCheckCmd"
>that has the same purpose and works almost identical,
>sure a stored proc would be a cleaner way but it was no option in the questioners context ..
>

I don't think the code is terrible either. The location of the code is the problem. It belongs in a stored proc - not T-SQL code rendered from the client. You may think this is a semantic issue. I can assure you it is anything but semantics. As far as the CursorAdapter Class is concerned, I don't put a lot of stock into that "feature". While it may deal with a symptom - the underlying issue still remains - your code is still on the client and not on ther server where it belongs.

The sooner you realize that the a server database is much more than a storage vehicle, the sooner you will be able to unleash the full power and potential of the backend.



>"Question: what is to stop people from sending code that ends up deleting data, dropping tables, constraints, etc?""
>
>could be solved with appbased login security.

No - it could not be solved with app-based security. The most basic flaw off the bat is that you are relying on app-based security when essentially what you are dealing with is a problem with data security.