I have noticed that if someone overwrites or deletes a system package you cannot recover the initial code. In my case, I have lost DBMS_OUTPUT package. Does anyone knows how to reinstall it ?
The package is created with the scripts dbmsotpt.sql (package spec) and then prvtotpt.plb (package body), though I have never executed these scripts directly. The scripts can be found under /rdbms/admin.
Related
when we publish python package, we use pip, which will trigger setup.py to build some necessary packages.
I'm publishing a golang package, I wish when my user gets my package, it will auto trigger a makefile (some scripts to prepare environment) before installation. Is it possible?
I wish when my user get my package, it will auto trigger an makefile (some scirpts) before installation.
That would allow you to execute arbitrary commands on my machine while I do some innocent looking go get github.com/yiw/totallyharmless because I want to use that package.
Is it possible?
I hope not. This happened in the past (through clever cgo stuff) and was fixed as this is a major security issue.
I'm setting new oracle db and want to add SRW package which is used for oracle reports.How to add this package and where can I found the functions and procedures of this package? Or should I write PL/SQL codes myself ?
Edit:DB is used for ERP.
From my point of view, you should install Reports as SRW built-in package is closely related to that product; that is, probably, the best option you might choose.
If you have a database to spare (as I can't guarantee that - if you follow what will be said next - you won't harm the database), find IAS installation which has Reports installed.
Navigate to its reports\admin\sql directory which contains several files, one of them being srwAPIins.sql which should install the SRW package (by calling other files located in that directory); it is editable, have a look at its contents.
Once again: don't do that if you don't know what exactly you are doing.
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.
I tried installing Essential.Diagnostics via
Install-Package Essential.Diagnostics
But I had an issue where it said I was referencing something that didn't exist, so I tried removing the reference, and now I don't know how to re-add it. When I run the above command in the Package Manager Console again, it keeps saying my project already has a reference to it, even though I can see in the Solution Explorer that it isn't there.
How do I fix this?
Just noticed a file called "packages.config" in my project. I opened that, and it contained the suspect package. I deleted the file and re-installed the package. Successfully added now.
I guess that leaves the question, how are you supposed to properly remove a package then?
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.