Re: DUAL table in Oracle

Scott suggestion looks great. Almost every DBMS now-a-days has its own function/procedure/package to return its engine details. Your cross platform application seems to be supported for 3/4 platform, so it shouldn't be a big issue to modify that routine to check the engine type (depending how modular coding of applicatin is). I have got many customers which runs their scripts and create many tables as a part of their scripts. Therefore, using native function would be better than checking dual table during exception handing. If you need, I can provide you native functions for many DBMS.

John fry wrote: > Scott suggestion looks great. Almost every DBMS now-a-days has its own > function/procedure/package to return its engine details. Your cross > platform application seems to be supported for 3/4 platform, so it > shouldn't be a big issue to modify that routine to check the engine > type (depending how modular coding of applicatin is). I have got many > customers which runs their scripts and create many tables as a part of > their scripts. Therefore, using native function would be better than > checking dual table during exception handing. If you need, I can > provide you native functions for many DBMS. Nothing is changing during code freeze, and that's for several weeks now. Ultimately the issue is with who has the authority to modify the database schema, and what third-party software is allowed to access or update data. We can't possibly warrant a database that is not under our control. All I wanted was to know what the purpose of the table is so that I can advise alternatives for the supplier of the rougue table. They are the ones who need to make the changes because they are not responsible for the warranty on the software or database. Thanks all for the information. It's such a trivial table, and yet this situation highlights just how common it is with computers for "oh it's a small harmless change" to completely muck up something that wasn't considered. Caution and thoughtfulness is always essential, but is too often lacking. I think ego and naivety is responsible for so many defects in computer systems... Hands up all developers who are happy if customers or 3rd party developers would change schema or use un-vetted programs to modify or access data. At the very least there are also probably privacy issues and also security issues. Hands up who is happy for anyone with a 3rd-party tool to make a listing of their salary? Their parking ticket history? Their bank balance?

Andrew Hamm wrote: > John fry wrote: > >>Scott suggestion looks great. Almost every DBMS now-a-days has its own >>function/procedure/package to return its engine details. Your cross >>platform application seems to be supported for 3/4 platform, so it >>shouldn't be a big issue to modify that routine to check the engine >>type (depending how modular coding of applicatin is). I have got many >>customers which runs their scripts and create many tables as a part of >>their scripts. Therefore, using native function would be better than >>checking dual table during exception handing. If you need, I can >>provide you native functions for many DBMS. > > > Nothing is changing during code freeze, and that's for several weeks now. > Ultimately the issue is with who has the authority to modify the database > schema, and what third-party software is allowed to access or update data. > We can't possibly warrant a database that is not under our control. > > All I wanted was to know what the purpose of the table is so that I can > advise alternatives for the supplier of the rougue table. They are the > ones who need to make the changes because they are not responsible for the > warranty on the software or database. > > Thanks all for the information. It's such a trivial table, and yet this > situation highlights just how common it is with computers for "oh it's a > small harmless change" to completely muck up something that wasn't > considered. Caution and thoughtfulness is always essential, but is too > often lacking. I think ego and naivety is responsible for so many defects > in computer systems... > > Hands up all developers who are happy if customers or 3rd party developers > would change schema or use un-vetted programs to modify or access data. At > the very least there are also probably privacy issues and also security > issues. Hands up who is happy for anyone with a 3rd-party tool to make a > listing of their salary? Their parking ticket history? Their bank balance? It depends...doesn't it always? If you had a table called dual, then you'd have every right as the DB provider to be upset. If you have an explicit set of rules about which table names users may add to the system and dual is not one of those names, then you'd have every right to be upset. If they had modified one of the tables you'd provided, you'd have every right to be upset. But none of these applies AFAICT. They've added a harmless table that you didn't appear to use to a database, which is, after all, a shared resource (Codd's original paper was "A Relational Model of Data for Large Shared Data Banks", after all). So, in general, adding a table to a database shouldn't break anything - if you've laid out rules on what's reserved to the primary application suite and what is permitted to the user. Obviously, most users should not have the resource (or DBA) permission necessary to add tables to the database. And, ultimately, you have to trust those who do (especially the DBAs - not to mention the DBSAs, the database system administrators, aka informix in most IDS systems). -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

> Nothing is changing during code freeze, and that's for several weeks now. Better late than never :-) > Ultimately the issue is with who has the authority to modify the database > schema, and what third-party software is allowed to access or update data. I agree with JL (>200%). One has full rights to upset, if any object belongs to thier application, been touched, but in reality, one can not restrict the user to create objects for thier need. > We can't possibly warrant a database that is not under our control. What about spending time on documenting DOs and DONT's and QA ? > All I wanted was to know what the purpose of the table is so that I can > advise alternatives for the supplier of the rougue table. I would have asked this quesion from user rather than asking here, just to leave the forum to discuss other technical issues. Ofcourse, knowning details of dual table in oracle was fair enough. > They are the ones who need to make the changes because they are not > responsible for the warranty on the software or database. > Thanks all for the information. It's such a trivial table, and yet this > situation highlights just how common it is with computers for "oh it's a > small harmless change" to completely muck up something that wasn't > considered. Caution and thoughtfulness is always essential, but is too > often lacking. Depends. How application has been designed. Depends how an object breaks the application. A lot many things to consider. > I think ego and naivety is responsible for so many defects > in computer systems... I would say "EGO" is more degerous. Dealing with techical defects could be far simpler than a human issue. This is more important in customer relationship paradigm as it can lead to loss of business as well. I have seen such a real life situation, beleive me. > Hands up all developers who are happy if customers or 3rd party developers > would change schema or use un-vetted programs to modify or access data. At > the very least there are also probably privacy issues and also security > issues. Hands up who is happy for anyone with a 3rd-party tool to make a > listing of their salary? Their parking ticket history? Their bank balance? There are lot of things to consider as mentioned by JL. I always recommend my clients to accepts JL's comments.