I totally agree: this absolutely seems to be an Oracle bug causing the problems! However, the quite serious consequences that can follow when working with a production database (even provoking the entire server to stop) deserves to be given attention from the pl/SQL developer side as well. It is very unfortunate for the good name and reputation of this excellent tool when we experience problems like the following: on a customer site, the simple action of connecting to the production database using pl/SQL developer caused oracle "ORA-00600 internal error" messages to bounce on almost every user screen. This was a serious incident!
The consequence might actually in the very worst case be that use of pl/SQL developer is banned, and another tool is enforced - which probably would make me turn into hysterical crying and screeming
Marco, you say the following "The only thing that could cause a server problem like this is the "Debug Information" in DDL or DML triggers. When you compile a trigger with the "Add debug information when compiling" preference, this adds debug information. Sometimes the Oracle Server can cause problems in such a case."
If this is the case, then it should be rather simple to add a warning about not using this setting in a production database? This would also prevent pl/SQL developer from getting the blame for what is actually an Oracle bug.
What I would like is to be able to enforce preferences settings that are safe, also when connecting to production databases. By this I mean to enforce such settings for all developers with no option of overriding that setting. If I understand the documentation correctly, the individual developer can always override the system settings set by the systems administrator. Or am I mistaken about this?
I would also like to be able to easily switch from one set of preferences to another, and to enforce such a switch to a given preferences set whenever the database is a production database.
I see that some settings can be tuned to different databases, by adding a list of connection strings that will use this setting. But the list of user@database is not very practical, since the number of users in a given database can be huge. The database in its own right is a production database or a test/development database, regardless of the user name.
For example, a property of the preference set could be "production", "test" or "development", and this could be matched to a list of databases that also have the same property. Then the preferences should be switched whenever the user conencts to a database of another database type.
So, my point is that I would like pl/SQL developer to help us in preventing such serious incidents from occuring.
With regards
Helene
