Another thing in this EA is that the APEX Export and Splitter have been combined in the apex.jar which is included. Once the apex.war is deployed the apex.jar is expanded out however if you want to use just this issue this to pull it out. I'll clean this step up in upcoming releases but for now here's how to test it out.
jar xvf apex.war WEB-INF/lib/apex.jar
Then you just issue the commands as normal. The new part is that they are joined and in one command line you can export and split.
$> java -cp apex.jar:/path/to/ojdbc6.jar oracle.dbtools.apex.utilities.APEXExport Usage APEXExport -db -user -password -applicationid -workspaceid -instance -skipExportDate -expSavedReports -debug -db : Database connect url in JDBC format -user : Database username -password : Database password -useAliasFileName : use alias.sql instead of f12345.sql -application : ID or name for application to be exported -workspace : Workspace ID or Name for which all applications to be exported -outDir : Directory to export to -instance : Export all applications -skipExportDate : Exclude export date from application export files -expSavedReports : Export all user saved interactive reports -split : Split the export files -flat : Split into a Flat file structure -update : < create update file > -nochecksum : < don't check for changes > Application Example: APEXExport -db candy.us.oracle.com:1521:ORCL -user scott -password tiger -application 31500 Workspace Example: APEXExport -db candy.us.oracle.com:1521:ORCL -user scott -password tiger -workspace 9999 Instance Example: APEXExport -db candy.us.oracle.com:1521:ORCL -user flows_020200 -password apex -instance
The other things new here are from a request from John Scott. There's a flag to name the files based on the alias instead of just the id. The application name or workspace name can be passed instead of the id.
The splitter has a few options:
-split
This is the main switch to turn on the splitting
-flat
Instead of directories it will use a single directory to put all the split up files.
-update
This will create an update.sql based on what changed from the last split that was done. It uses a checksum on the new and old to determine if there was a change in that section
-nochecksum
If you split f100.sql, you get all the split files. Normally, it will checksum that if page1.sql didn't change it will not update the timestamp on the file. If you turn checksum off it will always update the timestamp. The checksumming to update the timestamp is nice for things like checking into version control. Only the page/item/tab/.. sql scripts that changed will changed so you can see quickly what has and has not changed.
