I have exported my oracle apex application to take its back up.
It has multiple application files, page files, ui files etc. My apex version is 20.1 and i am using apex.oracle.com.
If i need to import this same application again, do i have to import all the individual pages one by one like they have been exported or is there a way to import them all at once?
I tried importing the zip file but its not working.
Please suggest a workaround to upload all files at once as there are around 40 page files apart from application files, user interface files, etc.
As far as I can tell, that won't work on apex.oracle.com.
I was thinking of Apex SQL Workshop, running multiple scripts at once (sequentially). Why? Because those export files are .SQL files so you can run each of them as a script. However, there's no such option.
If you load it into SQL Commands, it won't work because of invalid/unrecognized SQL*Plus commands such as whenever sqlerror exit sql.sqlcode rollback.
If it weren't for apex.oracle.com but your "local" Oracle database, the one you have access to and can use SQL*Plus, you could write a script that calls other scripts, but - as that's not your case, no use of it.
Therefore, I think that you'll have to import each of those files manually, one by one.
Each of the export files is a separate script containing a number of pl/sql blocks. You could try to contatenate them together into a single script, upload and run that. However there is a size limit to scripts so you'll probably have to use more than one.
Is there a particular reason you chose to export as zip?
You could just do a normal export, which will give you a single file with your application and most everything it needs all in one place and very easy to import when needed.
If supporting objects are a concern, create install scripts that build your tables, triggers, etc. and make sure to choose "Yes" or "Yes, and install automatically" in the "Export Supporting Object Definitions" drop down.
You can still download the zip too and stuff that into version control if that is needed, but for ease of restoring an application, the "normal" single file way is far easier to manage.
Related
I want to redeploy a package with sqlplus like that:
echo exit| sqlplus user/passwd#db #package.sql
I wonder if it would be possible to diff #package.sql with the existing package in db(if exists at all).
I'm using power shell for that.
Many thanks in advance!
I don't know whether you can do it using Power Shell. I'd
install Notepad++
then install its "Compare" plugin
use SQL Developer to easily access current package specification/body
copy/paste it into Notepad++
load package.sql into another Notepad++'s tab
compare both tabs
you'd see which lines are equal, which exist in one tab and not in another (and vice versa) - everything
If you want to do it "automatically" while running package.sql ... then
I have no idea how to do it,
might cost more than what I suggested ("cost" because you'd have to develop a program which would do that, and that takes time and effort), unless there's already some tool which lets you do it (but I don't know anything about it)
I'm trying to export an APEX application which uses some sequences and then install this onto a new APEX system. However everything is working except the sequences as they seem to not be included in the install file.
Exporting an apex application only exports the apex application. Database objects, such as sequences and packages, are not exported.
You could use the "Supporting Objects" feature of the application to create installation scripts as part of the application.
Within an application, choose "Supporting Objects". Select "Installation Scripts". Click "Create". Choose "Create from Database Object". You can then add objects to the script. Eventually an SQL file will be created and added to the application.
Exporting the application will then include the supporting objects scripts, and you'll get the option to install these when you import the application.
However (!), these scripts are NOT updated as you alter objects in the database. You'll have to recreate the scripts all the time.
I'm not a big fan of this way though. It's okay for a small app. Or if you have an app you'd want to distribute. I much prefer separate sql files for objects required.
If you're serious about your development you will treat apex and the database objects as separate entities. There's a reason why almost all apex developers try to keep their code out of apex where reasonable.
Other options are: export objects through sql developer (or toad, whatever floats your boat). You can easily create all the scripts for all the different types of objects.
Maintaining these files separately will also allow putting them in version-management much easier. When all your install scripts are in the apex application, not so much.
We're using database projects here at work and for our deployment to the production server, our current process is to manually run a compare using a saved .scmp file that compares the database project to our production database (using a read-only login), then generate a SQL script that we give to our I.T. support guy to run on production. We also do a build to generate our post-deployment script, and we give that one to our guy to run as well.
I'm trying to automate as much of this process as possible (to reduce the chances of mistakes and make it more efficient). I'd like to know if there's a way to automatically generate the sql change script using the predefined options in our .scmp file.
Additionally, is there an easy way to automate the appending of the post-deployment script to the end of the schema change script, so he just has one sql file to run?
Perhaps there's a nice way to do the whole thing with powershell or something.
Ok what you should do is use sqlpackage.exe to create your script from the dacpac that is produced by building the ssdt project.
Create a batch script to call it or make it a part of your CI process.
To filter the output there are some new options like exclude certain types in the latest (March 2015) release of ssdt or use a deployment filter like:
http://agilesqlclub.codeplex.com if you need more flexibility.
Using this you can filter the deployment like the compare and also the pre/post deploy scripts are pre/appended so you kill two birds with one stone!
Ed
I am using Oracle 11g. I had exported data using the installed version of SQL Developer to a sql file called "export.sql". Now, I have downloaded the new version which is 3.1.07 and when I try to import data by clicking on the tree view and choosing Tables | Import Data and navigating to "export.sql", I get the following error:
no readers are registered for the sql type
When I first started the application it asked for the path to java.exe and I have shown that path and application started. I have the started the application from the path where it was downloaded (C:\users\kaushik\Downloads\sqldeveloper)
You can call the file directly from sql developer.
Example: If you saved you file to c:\Oracle\MyBackups\Export.sql
Then from within Sql Developer, connect to your database and use the sql command:
#C:\Oracle\MyBackups\Export.sql
and that will execute the Export.Sql script.
If you have a valid SQL file, you simply need to execute the script. Open the file (File | Open and navigate to export.sql), hit the Run Script button (F5 on Windows), and choose the connection you want to use. The Data Import Wizard supports a number of different file formats (Excel, CSV, etc.). It doesn't support SQL files. If you want to ask the developers why they don't support SQL (or why they use the general file navigation dialog rather than using different dialogs for different sorts of files) you can ask them over in the SQL Developer forum on OTN. I assume the problem is that most SQL scripts contain much more than simple INSERT statements and it would be challenging to figure out whether any particular script was actually just a bunch of INSERT statements that could be used to import data.
Yes, SQL Developer is written in Java so you need to have an appropriate version of the JVM installed. Different SQL Developer download options include a bundled JVM or you can download a smaller file and use an already installed JVM.
One of oracle client tools to make session to database is sqlDeveloper and its graphical interface tool Programmed with Java Lang and its installed independently from oracle_home its a stand alone product and Of Course it needs SDK Or JDK to work
make sure to set the path and check it
read this link http://www.ehow.com/how_5127784_set-java-path.html
all of this if sql developer didn't run and other similar problem
this to answer
Is JDK is needed or what ? Yes
use sql Developer higher version
i am upgraded to Version 20.2.0.175
issue resolved
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.