May 22, 2008 at 1:03 pm
I realize some are going to laugh when they read this while others are going to have a bewidlered look and ask what is this guy talking about? There's no viable reason to use an Instead Of Trigger on a SELECT.
The situation is that we use an application with a SQL Server 2005 DB that is lacking in some very important areas for us and we are looking at ways to work around these with little to no change to what the stock database looks like and works. In this particular case there is a table that stores configuration values for the applications environment and we are trying to find a way to change what value is sent back to the application from the Table when a certain condition is True when the application is looking up this value in the configuration table.
I know an INstead Of Trigger can be used to alter what is INSERT, UPDATED and or DELETED based on criteria provided in the Trigger. I'm looking for a way to do the same with a SELECT. I've read about some using VIEWS to get similar functionality but that's not a favorable option for our situation. A view would require full maintenance of the source table and I'm only trying to intercept and change the traffic on a single item in that table and only when the value is being Selected and not when it's UPDATED, INSERTED or DELETED.
I'm open to any and all suggestions.
Thanks in advance
Kindest Regards,
Just say No to Facebook!May 22, 2008 at 1:18 pm
I know you've already said that a view may not work for you, but can you clarify what your concerns are with this? What do you mean by 'a view would require full maintenance of the source table'? This can easily be done with a view.
May 22, 2008 at 1:26 pm
If we use a view then we have to handle changes to the table be they UPDATES, INSERTS and or DELETES. This opens up a lot of issues because we have then stepped into the realm of altering the product in a significant way because we would then be responsable for making sure all configuration related portions of the application work and if anything didn't the responsability (aka blame) would fall back on us because we modified something that we weren't suppose to. If there were an Instead Of Trigger option it to would be modifying the tbale in way but only a very small portion of it and so the case could be made that anything outside of the single configuration setting we would be handling in the Trigger, would sstill be working as original and therefore the responsability of the software company should something go wrong.
Basically I'm trying to stay away from being accussed of tampering with the core program but still get to over ride the answer (what a SELECT would retrun) and 1 column of data in the table.
Hope that helps explain the situation.
Thanks
Kindest Regards,
Just say No to Facebook!Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply