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