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.
Related
I mistakenly deleted an ODI package from my project which is very large in size. Is there a way to recreate the same package if I have a previously exported scenario for the same project?
Unfortunately there isn't any way to directly generate a deleted package from a scenario which you can see as a compiled version of the package.
Here are a couple of things to check to see if you can retrieve some information :
When promoting from one environment to another, it's recommended to export the base object along with the scenario. That way you keep track of what was the code behind that scenario (black box). Bonus points if it's all versioned in a version control system (VCS).
Starting with ODI 12.2.1, VCS can be directly integrated within ODI to version your code and create release archives. If that's the case you can restore a deleted object
Before 12.2.1 it was possible to use the internal versioning system of ODI that would store the objects in the Master Repository. You can restore it from the top menu.
If nothing of that is setup, you can still open the scenario export in any file editor and manually go through it to retrieve the logic. It's just an XML files that describes the different steps of your package. That would help you to rebuild it manually.
If you end up doing that last bullet point, now is probably a good time to improve your existing procedures and setup one of the three backup/versioning solutions mentioned above so it doesn't happen in the future.
a little background, I really don't know any technical terms from Oracle. My company have a pre built machine and I'm trying not having to go there backup my files and lose a day of job because I cant.
Recently I'm learning how to use Oracle Designer (6i) to build a diagram and later a table so I can request it to be created... While using the software it requested to install some file for the repository... after doing it, It screwed up every Oracle product I was using... I couldn't connect to PLSQL or even the designer...
After fixing some registry to point to the right TNSNAME and manually adjusting PLSQL, I managed to access both. The problem in hand is in oracle Designer at the "Designer Editor", when I right click a table and select generate, the message bellow shows up
Message
-------
CDD-23564: The file "C:\ORACLE\DSG6I\BIN\cds61.dll" could not be loaded or does not exist.
Cause
-----
The specified file or one its dependent files could not be loaded.
This may be because a file has not been installed, or is not
correctly defined in the system registry.
As an example dependency, the Forms Generator files require the
Form Builder files installed as part of Developer.
Action
------
Check the registry settings for the location of the required
file. Also check the product and any required dependencies
e.g.Developer have been installed correctly.
If necessary, try reinstalling.
The dll mentioned IS and EXISTS on the mentioned folder.
Considering I don't have the Oracle Developer 6i intaller, what can I do? What registry entry should I update?
Designer 6 is long out of support. Oracle has a free tool, SQL Developer Data Model, which does not break.
Even Designer 9i was flaky and would crash at random intervals and poke along with larger schemas. Anything over hundred tables could take days to edit. Ah, good times...
I managed to fix the problem by copying and replacing the whole ORACLE_HOME\DSG6I folder (in my case c:\Oracle\DSG6I, for those confused in terms like me) and the oracle system registry (regedit > HKEY_LOCAL_MACHINE\SOFTWARE\Oracle) from a coworker machine!
I need to move Oracle package from one server to another. I created script and tried to compile it on new server but it failed beacuse there were few links on other packages and lots of other tables.
What is the best practice to move package with dependant objects?
Is it possible to create a script for this package, that will include create statement for each dependant object (package or table) ?
Thanks in advance!
There´s a free oracle tool, SQL Developer (http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html) that has an option for exporting databases, as .sql scripts with lots of options.
That might be what you need.
Hope it helps.
I'm curious to find out how people manage their packages in their applications.
For example, in our development instance, an application developer may want a change to a stored procedure. However, changing the stored procedure will break the existing Java code until the DAO layer is updated to accommodate for the changes.
My typical practice has been to put the new procedure implementation into a "DEV" package. The developer can then change his reference to this package, do his testing and then when we're ready, we can replace the procedure in the "production" package, delete it from DEV and the developer changes his reference back to the production package.
However, I'm finding it doesn't work as swimmingly as I'd like. First, if there's a bunch of Java code which depends on the DEV package, then I'm in the same situation as if were editing the production package directly - if I break the package, I'll break a bunch of code.
Second, people get busy and we don't get around to moving the package into production as soon we should. Then we have two versions of the stored procedure floating around and it gets difficult to remember what has been moved into production and what hasn't.
The goal is to keep the developers working. Yes, it's a development server, but we don't want to be breaking code unexpectedly.
Can anyone suggest methodologies that have worked for them to address this issue?
If each developer has their own schema in the database and there are public synonyms for all objects in the shared schema and all the Java code uses non-qualified object names, then a local copy of the package in a particular developer's schema will have precedence over the shared version. So developer A can take the current version of the package, install it in his or her local schema, make whatever changes are desired to the package, and make whatever Java changes are necessary all within their own development environment (I'm assuming that developers have their own local app server). When both sets of changes are sufficiently stable that they can be checked in to the shared development environment, both the PL/SQL package and the Java changes can be built out to the shared development environment (the shared development app server and the real schema in the development database). The developer can then drop their local copy of the package.
That approach works reasonably well so long as the developers are checking the PL/SQL out of source control to start their changes rather than assuming that whatever local copy they have in their schema is current-- if developers keep old, local versions of code around in their local schema, they may end up with difficult to debug issues where their PL/SQL and Java versions are out of sync. You can resolve that problem by automating processes that, for example, drop packages from developer schemas if they haven't been modified in a reasonable period of time and if those packages aren't checked out by the developer in source control or by building scripts that let a developer automate the refresh of their schema as part of the build process.
The Java/DAO layer should only be affected if the procedure specification changes (ie number, name etc of parameters). Mitigation strategies for this are
Add new parameters with DEFAULT values for parameters so that they don't need to be passed.
Don't change the order of parameters if they cat called positionally [eg pkg.proc_a (1,2,3)], or rename them if called by name [eg pkg.proc_b (p_1 => 1, p_2 => 2)]
Use packages for procedures and functions so you can overload them
create or replace pkg is
proc (p1 in varchar2);
proc (p1 in varchar2, p2 in number);
end;
With overloading you can have multiple procedures with the same name in a package just with different numbers and/or datatypes of the parameters
11gR2 has introduced Editioning to solve this problem. It allows multiple versions of packages and the application code choose which 'edition' (version) of the code it wants to see - the default 'base' edition or a development version.
However I suspect upgrading the database version isn't a practical solution.
I'm working in a multi-developer environment in Oracle with a large package. We have a DEV => TST => PRD promotion pattern. Currently, all package edits are made directly in TOAD and then compiled into the DEV package.
We run into two problems:
Concurrent changes need to be promoted on different schedules. For instance, developer A makes a change that needs to be promoted tomorrow while developer B is concurrently working on a change that won't be promoted for another two weeks. When it comes promotion time, we find ourselves manually commenting out stuff that isn't being promoted yet and then uncommenting it afterwards...yuck!!!
If two developers are making changes at the same exact time and one of them compiles, it wipes out the other developer's changes. There isn't a nice merge; instead the latest compile wins.
What strategies would you recommend to get around this? We are using TFS for our source-control but haven't yet utilized this with our Oracle packages.
P.S. I've seen this posting, but it doesn't fully answer my question.
The key is to adopt a practice of only deploying code from the source control system. I'm not familiar with TSF, but it must implement the concepts of branches, tags, etc. The question of what to deploy then falls out of the build and release tagging in the source control system.
Additional tips (for Oracle):
it works best if you split the package spec and body into different files that use a consistent file pattern for each (e.g. ".pks" for package spec, and ".pkb" for package body). If you use an automated build process that can process file patterns then you can build all of the specs and then the bodies. This also minimizes object invalidations if you are only deploying a package body.
put the time in to configure an automated build process that is driven from a release or build state of your source control system. If you have even a moderate number of db code objects it will pay to be able to build the code into a reference system and compare it to your qa or production system.
See my answer about Tools to work with stored procedures in Oracle, in a team (which I have just retagged).
Bottom line : don't modify procedures directly with TOAD. Store the source as files, that you will store in source control, modify then execute.
Plus, I would highly recommend that each developer works on its own copy of the database (use Oracle Express, which is free). You can do that if you store all the scripts to create the database in source control. More insight can be found here.
To avoid 2 developers working on the same package at the same time:
1) Use your version control system as the source of the package code. To work on a package, the developer must first check out the package from version control; nobody else can check the package out until this developer checks it back in.
2) Don't work directly on the package code in Toad or any other IDE. You have no clue whether the code you are working on there is correct or has been modified by one or more other developers. Work on the code in the script you have checked out from version control, and run that into the database to compile the package. My preference is to use a nice text editor (TextPad) and SQL Plus, but you can do this in Toad too.
3) When you have finished, check the script back into version control. Do not copy and paste code out of the database into your script (see point 2 again).
The downside (if it is one) of this controlled approach is that only one developer at a time can work on a package. This shouldn't be a major problem as long as:
You keep packages down to a reasonable size (in terms of WHAT they do, not how many lines of code or number of procedures in them). Don't have one big package that holds all the code.
Developers are encouraged to check out code only when ready to work on it, and to check it back in as soon as they have finished making and testing their changes.
We use Oracle Developer Tools for Visual Studio.NET...plugs right into TFS
we do it with a Dev database for every stream, and labels for the different streams.
Our Oracle licensing gives us unlimited dev/test instances, but we are an ISV, you may have a different licensing option
You can use the Oracle developer tools for VS or you can use sql developer. SQL developer integrates with Subversion and CVS and you can download it for free. See here: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html
We use Toad for Oracle with the TFS MSSCCI provider against TFS 2008. We use a Custom Tool that pulls database checkins from source control and packages them for release.
To my knowledge Oracle Developer Tools for Visual Studio.Net doesn't have any real source control integration with TFS or otherwise.
You might consider Toad Extensions for Visual Studio though it's not cheap, maybe $4k I think.
Another option is the Oracle Change Management Pack but believe it requires the Enterprise edition of Oracle which is much more pricey.
You may be interested in Gitora www.gitora.com. It helps managing Oracle database objects with Git.
This article about collaborative development with the Oracle database can also be helpful: http://blog.gitora.com/plsql-how-to-develop-two-features-simultaneously-but-deploy-only-one/
Full disclosure: I am the developer and author of the article.