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.
Related
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.
I have just implemented my DB Schema with Jetbrains new DataGrip IDE. The schema now exists on my DB server instance that is running locally.
In other IDE's I can save the work as a "Project" or save the SQL to a file. I don't see any option in DataGrip, except for Copy DDL, which I have tried and it copies my schema along with a lot of other stuff.
Is that the only option or am I supposed to do it through a PostgreSQL management tool. I want to save my work.
Thanks. Also, please don't just mark this to be closed. I have seen many other questions like this on StackOverflow. i.e. Asking how to perform some action on a tool related to software development.
You are in "default" project by default. Go to File/Project and create your own which can be opened later by File/Open recent, for example.
I'm working on creating a deploy script to migrate new development from our dev server to our uat server. Unfortunately, the devs that made the changes didn't script them out at they coded. The easiest way for me to approach this is to use SqlDeveloper's database diff functionality. It does a good job of highlighting the differences and creating a script that I can run on UAT. However, I've noticed that it doesn't take into account any dependencies. For example, a it will put a command to create a table below a table that references it in a foreign key constraint. Because the referenced table doesn't exist yet, the first table create command fails. I've seen this with views referencing packages, packages referencing packages, etc. Is there any easy to way either 1) force sql to export in a "smarter" order or 2) manually calculate the dependencies (ex: querying USER_DEPENDENCIES, etc) so that i can manually sort the file of create commands without resorting to trial and error? I guess we could consider purchasing a commercial product as long as it matched exactly what we are looking for.
Note: we will probably have to deploy to UAT multiple times in order to support testing by end-users. I am trying to automate this as much as possible so I don't have to manually recreate this script every single time!
Thanks!
I am trying to move an existing database into a VS 2010 database project. This database has been around for a very long time and has a lot of stored procedures. Many of those stored procedures create working tables using the SELECT ... INTO syntax. This was done at the time to reduce the amount of data going through the transaction log. When I import the database into the project I deselected the work tables. Now when I look out the warning I see all of my stored procedures are saying that they can't find the work tables. Does anyone have a way of dealing with this? I am slowing converting as much as I can to SSIS but there is some logic that will have to remind in the stored procedures.
Thanks.
In this case you either have to ignore the warnings or import those working tables that are absolutely required for the stored procedures to work. I don't think the project will build properly if the tables are not present, but are expected.
If those tables are already present in the database, you should be fine as they won't be re-created. You can slowly deprecate them as you clean up your stored procedures.
I'm trying to use VS 2010 Sql Server Database Project to keep track on changes made on my database and to generate appropriate scripts when a change needs to be deployed from dev to production environment.
I have created my schema comparison between my dev database and the project schema which does a great job. However, I cannot find a way to create incremental scripts, the only things I get are scripts with CREATE statements (Export to Editor option).
Am I doing something wrong?
Thanks in advance.
As part of our auto build process, we store .dbschema files for each environment in source control. During the build, we create the .dbschema file based on the database project and then use vsdbcmd command line call to generate the change script between the project schema and each destination DB schema. If you need specific command line call, let me know.
If you're using "Data Dude" correctly, these are done for you and run when you choose Deploy. Just keep your schema (tables, stored procs, populate scripts etc) as a project item and change it as you need to. The build-and-deploy process will generate the scripts. http://msdn.microsoft.com/en-us/library/ff678491.aspx is a not-bad starting point if you want to get these scripts and run them youself against various staging, production, etc databases.
In the .deploymentmanifest file there are two settings:
<DeployToDatabase>False</DeployToDatabase>
and
<DeployToScript>True</DeployToScript>
Running vsdbcmd will then generate the change scripts without affecting the target database. All you'd need is a version of the database which is the same as the production version, or access to point vsdbcmd at production to generate the script.