RE: Not storing the DDL was: Changing an SQL table (Best practices)

Rob,

I'm probably a special case. :-)

If the table is a part of the main application systems, it's in Aldon.

If I'm doing something outside the CMS, I don't bother to try saving the
source.  I've tried saving it, but even with just me working on it I
could never remember if I had by chance updated the object without
updating/saving the source.

The fact is, IMHO, given the ease of retrieving the source, SQL objects
are too easy to change without finding the old source.  If you don't
have an actual CMS and authorities setup which prevent a developer from
operating directly on the objects.

For a decent size shop without a CMS, I'd be very afraid.  You had to
have the old source for RPG and DDS objects, which lead to having "best
practices" for managing it.  For SQL objects, you don't have to have the
source. 

I'm under the impression that not saving the DDL is pretty common in the
SQL Server/Oracle/ect worlds.

Given the headaches of recreating a table with key constraints, ALTER
TABLE is the most logical way to make changes.  The use of ALTER TABLE
just doesn't play well with "managing the source" outside of a CMS of
some type.

As with RPG programmers whose first use of SQL DML is a record-at-a-time
processing, I'm wondering if we need to force ourselves to think
differently about SQL DDL.

The only downside I've run into generating the SQL source when needed is
that I lose my nice pretty formatting.

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, January 11, 2007 4:56 PM
To: Midrange Systems Technical Discussion
Subject: Not storing the DDL was: Changing an SQL table (Best 
practices)

<snip>
Actually, I end up not storing it at all.

I use iNav to generate the current source, make my change, 
add the drop
table line and recreate it.
</snip>

Charles I really hate to say this, because it gives the Luddites and 
naysayers ammunition to stick with DDS.  However, I have had 
more than one 
table that had constraints that I can no longer do a DSPFD 
and see the 
creating SQL.  The DSPFD errors out with a MCH* error.
But the cool thing is that your iNav trick still works.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

-- 
This is the Midrange Systems Technical Discussion 
(MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.