This content has been marked as final. Show 8 replies
Tools|Preferences|Code Editor|Link Stored Procedures to Files will do some of what you want.
You still have to explicitly save the files.
That option was already checked unfortunately and there wasn't any documentation available for it when I clicked the help button in the preferences dialog.
Is SVN integration something of an unfinished extra feature? It's considerably less than seamless.
I gave up on SQL Developer's version control a long time ago. I manage with a bunch of scripts to extract database objects to the file system where I manage them with CVS or SVN. This requires a lot of discipline on my part, and is likely to fail badly in a team of more than a handful.
When it was first being developed, I argued for better integration with the database, but it never happened. There is a statement from Sue Harper (former product manager) on this forum that version control in SQL Developer will always remain purely file based.
You can open the 'files' navigator to navigate to the files on file system. By clicking the file the normal code editor is opened. By pressing the 'compile' button in the button bar you compile against the db.
The only disadvantage is that you have to connect to the db for each file.
After making the change in the editor you press the 'save' button in the toolbar.
That's very much the impression I get. I do it all manually and will probably continue.
I would do that, but unfortunately we already have lots of files in SVN which were saved using the "Save package spec and body" option to save to a .pls file.
The problem is that when you open the resulting file and click compile SQL Dev gets confused because the spec and body are in one file together. Clicking the Run button doesn't work either, it just complains about not being able to find the "file based package".
All pretty frustrating and not worth the time investigating unfortunately.
Then you write a script which splits the .pls files in two pieces (a .pkb and a .pks file) and save those files in SVN.
Then you have two files which you can manipulate independently.
Disclaimer: I work for Red Gate
As others have said above, there are ways of getting most of what you ask for with the SQL Developer integration. Having said that, our experience is also that these are largely manual processes that require discipline, especially difficult in larger teams and near impossible if you wish to work in sandboxed (1 per person) schemas.
If third party, commercial tools are an option for you, our Source Control for Oracle tool integrates with Subversion (and TFS) and updates files automatically when you make database changes. We also split out package headers and bodies into separate files. Unfortunately this tool is Windows only, which I realise may be an issue for you.