By Jim Keansuai - 4/27/2009
Hi all, Jim here.
Currently i having an issue while upgrading the existing database by DDT. Existing database containing trigger that not created by DDT. Now after i install DDT supposed to only modify the structure of database by without removing the existing trigger.
I had checked the DDT, inside do not contains any new trigger/ any history on deleting the trigger. Do i have miss out any setting i can do?
Does anyone can provide some guideline on the this issue?
Thanks a lot.
|
By Aaron Young - 4/28/2009
Hi Jim,
Where have your database triggers come from if they were not part of the original DDT package? You can create triggers within the DDT and I would assume they would have been imported via the Import Database Structures option (haven't imported triggers myself but I assume it would work).
However, if your triggers are being added by SQL Server (maybe for replication) after you have deployed the database then you may have a problem as there is currently no way to tell DDT to leave these triggers in place. Check this post for more information:-
http://forum.strataframe.net/Topic22646-12-1.aspx
Aaron
|
By Sierra Fourwinds - 4/28/2009
Jim, I am also a StrataFrame beginner. I read your post and am most interested in the replies you receive. I am not going to need SQL replication features, but will need to use a 3rd party tool for database field-level change auditing. All the tools I have evaluated use triggers. I also would like to know how to use the DDT in a way that would leave these types of triggers in place. For us this would be a must have feature. Just wanted to insert this comment into this topic b/c I have posted a question about the auditing features in SF and know I must use a 3rd party tool w/ database triggers to handle the large volume of transactions and audit records created.
|
By Greg McGuffey - 4/28/2009
I know that in a few other areas (views I believe) the DDT now can actually leave pre-existing SQL items alone. However, if this hasn't yet been implemented (I don't if it has or not), you could use the post deployment script to add those extra triggers back in.
|
By Aaron Young - 4/28/2009
There are many third party reasons why triggers will be added (replication, auditing, etc.), I guess it would be really useful to have an option to ignore all existing triggers to overcome this. In addition, some third party add-ons will create additional indexes and these would also be currently removed by the DDT. Maybe an option to leave all existing indexes in place would be a good idea. This would also help with local database administrators who profile their own databases and add in recommended indexes from SQL Server too.
Aaron
|
By Trent L. Taylor - 4/29/2009
In short, the SPROCS and VIEWS already have this logic implemented. When a SPROC or a VIEW is created through the DDT a database property is assigned to the code element in question that designates that the SPROC was deployed with the DDT. The triggers, on the other hand at the moment, will be cleared out and re-deployed. This is due to dependencies. However, this has already been added to the list and will be in a near update. My recommendation, however, would be to ensure that all of the trigger in which you need to support at the moment are part of your meta-data so that they are recreated as part of the deployment.
|
By Sierra Fourwinds - 4/29/2009
Trent, this makes using the DDT more difficult on larger projects for sure in the meantime where there are 100+ tables and 40 of them all have 3rd party triggers installed by a 3rd party for field-level audit tracking for regulatory puposes. Having the DDT not remove these would be real desire for our company.
|
By Trent L. Taylor - 4/29/2009
Thus my previous post. This has been on the list for a while and will be implemented in a future update. Thanks. 
|
By Keith Chisarik - 9/2/2011
can you clarify when this will be implemented, I see the post is from 2009 and I still have 3rd party triggers that get wiped out. It is a big problem for us.
|