IncredibleMrT
Member²
Hi,
The above option comes in really handy when compiling against a live system. I know we shouldn't, but that's not the point.
Packages, functions, procedures - if I make a mistake, it isn't rolled out into general usage because the compilation is against a temporary object created only at the time of compilation. Great!
One niggle I have, is that the very same applies to triggers. Whether my code fails or not, it creates a new version of the trigger to compile against. That means I have two or mode (depending how many times i've compiled) identical triggers firing and possibly doing a job for as many times as there are triggers against it.
It would be great if this feature also dropped the object afterwards - that way it saves the ever growing list of owner.P$blah objects, and stops the trigger issue in it's tracks.
Thanks
Matt.
--
PL/SQL Developer
Version 11.0.6.1776
01.105297 - 5 user license
Service Contract: 01/01/2019
Windows 7 (64-bit) Build 7601 (Service Pack 1)
The above option comes in really handy when compiling against a live system. I know we shouldn't, but that's not the point.
Packages, functions, procedures - if I make a mistake, it isn't rolled out into general usage because the compilation is against a temporary object created only at the time of compilation. Great!
One niggle I have, is that the very same applies to triggers. Whether my code fails or not, it creates a new version of the trigger to compile against. That means I have two or mode (depending how many times i've compiled) identical triggers firing and possibly doing a job for as many times as there are triggers against it.
It would be great if this feature also dropped the object afterwards - that way it saves the ever growing list of owner.P$blah objects, and stops the trigger issue in it's tracks.
Thanks
Matt.
--
PL/SQL Developer
Version 11.0.6.1776
01.105297 - 5 user license
Service Contract: 01/01/2019
Windows 7 (64-bit) Build 7601 (Service Pack 1)