Create a trigger that only allows a certain role to update the data. Then, set up an application role to use.

This should pretty much duplicate what you have now.

BOb



>>I'm going to play dense here so disregard it if you have already had these battles with "them".
>>
>>SQL Server already has a very robust security model built into it. I don't see the need to add any outside influence. You can limit the access down to the operation on each individual table, view and store procedure using User logins and Roles.
>>
>>How secure do they need it to be? Or do they want to bypass this because they think this other way is better? While it sounds great for VFP because there is no built-in security, it is totally superfluous for SQL Server.
>
>It's a long story but basically the system was not properly designed from the start. No RI, poor normalization, improper (or no) key definition, no separation of the business rules from the UI. For their own safety, we can't allow users to make changes to the data EXCEPT thru the app.
>
>Basically the DB is being ported AS IS into SQL, so few if any of these issues are being addressed. In addition, there's nothing to prevent client from giving users access to the Query Analyzer and allowing them to muck up the data at will. So in a sense we can't take advantage of SQL security.
>
>Trust me, I'd rather use SQL security if I can find a way to.