How trigger could be tied to the client? You're reading something in my messages that isn't there.


>Thanks for the help Sergey. I am going to try a few other things. I really don't want the audit capabilities of the system tied to the client.
>
>Robert
>
>>I suggested, that you create VFP application to generate T-SQL code for each trigger. You can create a template for a audit trigger and than just fill it using fields for a specific table.
>>
>>>Thanks for responding Sergey. It's a pretty small system, so I'm not that concerned about performance. I'll have Agent go out and purge old records once a month, so file growth also isn't a problem either.
>>>
>>>Are you saying that I should remove the trigger code and initiate the code from my application (via SPT)? If so, I'd rather leave the code in the trigger, so the audit record gets created regardless of which client application updates it.
>>>
>>>Also, would I be able to access the inserted and deleted tables from within the SP if I took my original approach?
>>>
>>>Thanks again for all the help.
>>>
>>>Robert
>>>
>>>
>>>
>>>>For performance reason I would siggest that you approch this task from different angle. Create program/application that will generate a trigger script for each table in DB.
>>>>
>>>>>I am writing an audit log which will store old and new values when a given record changes. Instead of hardcoding every field name in my update triggers (a coding and maintenance nightmare), I am hoping to be able to write a stored procedure/UDF that will do the job.
>>>>>
>>< snip >