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.
Related
So I have this source code of a software which is probably developed in oracle.
Can anybody tell me how can I turn this into an actual software?
I am a newbie.
Screenshot
Those are Oracle Forms (.fmx) and Reports (.rep) executables, as well as a Menu module (.mmx). In order to run them, you'd first have to know which Oracle Developer Suite version it is; might be anything from at least 4.5 over 6i/9i/10g or even later; who knows, they all share same extensions.
Forms up to 6i are client-server; later versions are web-based so you'd have to install IAS (Internet Application Server) or WebLogic server; none of those installations is trivial so - if you can't even recognize what you have, you'd rather not do that on your own - consider hiring a consultant.
Once you manage to set it up, you'd run the .mmx file as it looks as the menu for that application.
However, it's not that simple - in order to run such an application, you have to establish connection to the database, i.e. a schema that contains tables used by this application. There's the "Database" folder - maybe it contains some more useful info, perhaps export file (.dmp), maybe even .dbf files ... can't tell just by looking at the icon.
It might be enough if all tables are owned by the same user; otherwise, application might fail because of missing dependencies.
Finally, I think that your best option is to find out someone who actually knows what it is, which development software was used to create those forms & reports and then see if something can be done. It would be simpler/easier if you had .fmb and .rdf (or .jsp) files instead of executables as you could edit them.
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.
I am using Apex4.0.2.
Does anyone know what kind of query Shared Components / Static Files uses?
It is certainly a view on WWV_FLOW_FILE_OBJECTS$.
But looking at view APEX_WORKSPACE_FILES not all
(workspace_id - workspace_name - application_id - application_name - mime_type)
appear in Shared Components / Static Files
I am using Ant to assemble and upload static files to oracle because it's quicker than using the interface. The result in WWV_FLOW_FILE_OBJECTS$ is usable but doesn't appear in the interface under Shared Components / Static Files which would be good to have.
Is there an auxilliary table involved?
Alastair
My suggestion is don't do this. Messing around with undocumented, internal storage is probably going to end in heartbreak. Do you never intend to upgrade your Apex instance? Who knows if this will keep working once you do that. I'm assuming this is "too slow" as you move an application from one instance to another?
My first suggestion is upgrade to Apex 5.x. When you do an application export, the application files (not the workspace files) go with the application and are installed when you install the application. Which, by the way, you can do from sqlplus in a script.
If you're stuck with Apex 4.x for the moment, what I did was to add the files to the application, then create an install script (I forget what section of Apex you do that in) that installs the files. This is a little annoying, because every time you change the file, you have to delete the script and recreate it.
I have a Visual Studio 2010 database project and I'd like to do a partial deployment, i.e. of specified objects. Is this possible? The only options I can see are to either do a full deployment or stop after generating the script.
For example, I'm changing many tables and stored procs but not everything is 100% finished and I'd like to push out a specific stored procedure to my test database, including its permissions, etc.
I read a little bit about SQL Server Data Tools, which apparently supports this, but I'm not clear on whether I'd have to migrate my database project to use that instead (would also need the ok from team lead), or if it's simply a plugin that would allow extra functionality.
Check out Schema Comparisons. They allow you to select the objects you want to deploy. They are available without SQL Server Data Tools.
A "partial deployment" is actually a little dangerous. Consider that you will have just built your database project, your entire database project, complete with the table changes, and it has built with no errors or warnings (right?). Now you want to deploy just your stored procedure, into a database that does not have the table changes.
Your stored procedure got no errors or warnings in the context of all the changes. Are you sure it will get no errors or warnings without those changes?
You should consider a source control solution to this problem. Save a copy of your stored procedure, revert to a version of the code that matches the database you'll be deploying to, then make your stored procedure changes to that. When you deploy, you will be checking to see if the stored procedure makes sense in the context of the database you'll be deploying into.
I am trying to create a database project in Visual Studio 2012/2010 where I need the CDC (Change Data Capture) tables , because lot of my views are dependent on the CDC tables. I couldn't find any way to import the cdc schema/tables :(. Read in many blogs that importing cdc is not supported. Is there any work around. Please suggest
Generally you wouldn't really want the CDC tables to be created by a database project, you want them to be created using sys.sp_cdc_enable_table
If you allow the database project to create the tables in a normal manner then the CDC tables would end up existing but their Change Data Capture wouldn't actually be enabled.
Obviously you can script the calls to sys.sp_cdc_enable_table in either Pre or Post scripts, but as far as I can tell neither place is ideal.
If you put the sys.sp_cdc_enable_table calls in a Pre script changes are that not all the original tables exist (on a fresh deploy none of them will exist), or that these original tables will change shape as part of the main deploy that occurs after Pre is run.
If you put the sys.sp_cdc_enable_table calls in the Post script, you can't have Views that rely on the CDC tables existing deployed as part of the main database project deployment (not without errors or warnings in your DB project).
I would suggest not having too many views, functions or stored procs that rely on the existence of the CDC tables, but it sounds like it might be too late for that.
Side Note: Generally speaking you should be using the cdc.fn_cdc_get_all_changes_ and cdc.fn_cdc_get_net_changes_ functions rather than referencing the cdc tables directly, see Querying Change Data Capture data
However, that just moves the problem along one level to those functions not existing in your project.
Unfortunately, there doesn't seem to be a good way to have those extra views without scripting them at the same point that you script your calls to sys.sp_cdc_enable_table
(I'm honestly hoping someone else will come along with a better answer that actually solves the problem)
We came across the same issue recently in a DB project using TFS/VS for builds during the implementation stage.
As Scott correctly said, it's not a good idea to attempt to implement either cdc schema or any objects inside the project/solution, this has unfortunate consequences which you really do not want to experience!
For TFS/VS projects, you should implement a Pre-PostDeployment Script strategy, whereby CDC can be disabled during the PreDeploy process and then the instances are recreated during the PostDepolyment process.
In this way you can assured that the correct CDC instances are created uniformly.
When you consider the dependent views, again, the strategy is not difficult.
Create the view as you normally would in the project, but as a placeholder (e.g. a simple CREATE dbo.vMyView AS SELECT 1 FROM SomeTable). In the PostDeployment scripts, add a further script that executes AFTER the CDC instances have been created, with ALTER statements for those views (e.g. ALTER VIEW dbo.vMyView SELECT Col1 FROM cdc.MyCDC_CT). Remember, a view, once created, can exists even if the underlying table doesn't.