Simple answer:
Use Textpad or another text editor.
Explanation:
For me PL/SQL development is a process that has evolved over time. I've tried to apply continuous improvement to SQL development and it has worked out wonderfully for me. (for more on continuous improvement/Kaizen see link text)
I found PL/SQL IDE tools to be unstable.
I've had several crashes of Quest Software's TOAD as well as Quest Software's SQL Navigator (I've been using it since Version 3).
I lost work.
I tried other IDE PL/SQL tools.
These tools also crashed.
I lost work again.
I got frustrated.
I do not trust PL/SQL software development to any of the PL/SQL IDE tools out there.
Here are my PL/SQL coding core practices:
1. Export code using Quest Software TOAD
2. Use a Cygwin bash script to move files into the appropriate directories
3. Compare versions via BeyondCompare (if needed)
4. Check code out of WinCVS / CVSNT (if needed)
5. Edit using TextPad
6. Compare versions via BeyondCompare (if needed)
7. Check code in to WinCVS / CVSNT (if needed)
8. Use a Cygwin bash script to create a master changes file.
9. Import code back using Quest Software TOAD
An even more lengthy explanation:
I use Quest Software TOAD to export all PL/SQL and table DDL code to the filesystem.
In the Database menu -> Export -> Source Code
In the Database menu -> Export -> Table Scripts
This gets me individual files for each database object.
I move these files (Cygwin bash script) in directories
based on the file extensions.
*.prc files in /procedures
*.fnc files in /functions
*.pks and *.pkb files in /proceudres
*.trg files in /triggers
*.vw files in /views
*.sql files in /table_scripts
These files are initially checked into CVS.
(I use WinCVS/CVSNT server side)
I Beyond Compare each file version exported by TOAD
with the version already in CVS.
I ensure that the CVS sql repository is up to date.
In other words I need to have a good starting baseline.
I then use TextPad to edit the PL/SQL code.
link text
I pre-configure my Textpad with SQL syntax files
to make it easier on the eyes
link text
After editing, I Beyond Compare each edited
file version exported with the version
in WinCVS.
Luckily, WinCVS allows you to use an external
diff (Beyond Compare) which comes in very handy.
I load the new/changed code via TOAD to a test schema.
In the SQL Editor menu -> Load and Execute a Script File
I test the code out. (do some debug runs)
If the code tests out, I check the code into CVS.
At the end, I use Cygwin bash (and a bash script I've written) to create a master changes file. This master changes file contains all of the changes that need to be applied to bring the live schema up to date. This saves me a lot of time.
I then load the new/changed code via TOAD to a live schema. In the SQL Editor menu -> Load and Execute a Script File. That's about it. Software engineering is about process, versioning (CVS) and automating builds (bash script).
The biggest lesson out of all this (that have made me 10 times more productive) was switching from DB-based PL/SQL IDEs to simple ASCII text files. KIS in action.
If a copy your code resides in an ASCII file you avoid:
- mucking up the DB
- locking up DB objects
- iffy DB based revision control tools (if any)
- iffy DB diff tools (if any)
- losing code due to IDE crashes
- losing code due to DB crashes / shutdowns
- losing code due to concurrent editing (this can happen if two or more PL/SQL developers edit the same procedure)
Instead if you handle all PL/SQL code in filesystem ASCII files you have
- your choice of text editors (TextPad,notepad++,vi,etc)
- your choice of revision control systems (CVS,svn)
- your choice of text filtering/handling/scripting systems (I like Cygwin bash)
- your choice of diff tools (Beyond Compare,WinDiff,diff)
- your choice of DB tools (I can use TOAD, SQL Navigator) for importing and exporting the PL/SQL code to files.
I wanted a version history of all code changes.
I wanted to get everyone working together and prevent developers from stepping on each other's toes.
I wanted the freedom to choose my tools.
The side effect of this is that I handle all of the DB code in the filesystem during rapid development.
Just my 2 cents.
