I just don't want to jump through too many hoops. I hate hoop jumping, which is what I'm doing now. I've been spoiled on other database platforms.
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: Tuesday, May 21, 2013 1:20 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Change column name on DDL SQL table in iSeries Navigator
On 21 May 2013 09:07, Matt Olson wrote:
I think a DCR request is the way to go.
No harm in asking. Personally I would not wait for the DB2 for i SQL to add that specific feature, in order to effect a correction that is required more presently... as that could be a long wait :-) I would instead do what is necessary with what is available presently, to get done what I needed done... presently.
There is no way it needs to be nearly this complicated.
Whatever enhancement *I* desire should exist, is a trivial matter to be provided to me, whenever *someone else* has to do the work to make that feature happen ;-)
The combined requests RENAME and CREATE VIEW to logically effect the renamed column is fairly trivial. And hardly complicated, especially if there is a GUI or script generator used to assist in the creation. The typical production application will never have any knowledge of nor any requirement to know, that the name reference is to a VIEW versus a TABLE; i.e. only maintenance requests such as those which might ALTER or GRANT would care about TABLE vs VIEW, but a requester of DML remains oblivious and unconcerned. This is effectively the same /resolution/ anyone would likely have used for RLA as well; i.e. CRTLF to make a new RcdFmt, then the applications use the LF instead of the PF.
And FWIW, a SQL stored procedure could implement the required scripted actions fairly easily, for the more literal effect of a renamed column within a TABLE, but of course with the consequences of the DROP COLUMN. For example, the request to CALL RENAME_COLUMN ('Schema_Name.Table_Name', 'Old_Column_Name', 'New_Column_Name') could perform the required ALTER activity for a particular column of a TABLE, having defined the routine RENAME_COLUMN to use dynamically generated requests from information in the catalogs [or from DSPFFD or similar].
They can look at how MS SQL Server does it as a good model to base it
off of.
I do not think they will need to see anything else to determine how to implement such a feature on the object-based IBM i OS that must also consider effects for its integrated /database file/ objects that contain the definitional attributes which are merely reflected in the catalogs.
The DB2 for i SQL will implement what is in the [ANS] standards for the language to accomplish an effective RENAME COLUMN. Other databases operating within a separate ecosystem to define their SQL /database/ via textual definitions, would not do well to serve as a model for the fairly unique DB2 for i using the integrated object-based model.
Or just execute the alter column syntax that was previously referenced
which exists in LUW version of DB2 but seems to be missing from IBM
i's DB2 flavor (these two development teams really need to grab a cup
of coffee and talk to each other once in a while).
See here:
http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.i
bm.db2.luw.admin.dbobj.doc%2Fdoc%2Ft0020130.html
If the feature is part of the SQL standards, or even just as pressure to be more compatible with what is provided by the DB2LUW SQL, then the feature [even if not all the same capabilities] will likely come to the
DB2 for i SQL; eventually, DCR or not. A DCR however, will show there is interest from actual customer(s).
IMO the ability to rename a column is rather worthless, as compared to whatever else the DB2 for i and its SQL could provide. I would much rather have a stored procedure to effect *CALLLVL scoped overrides, the double quote enabled as a literal\constant delimiter, and a slew of other things. I perceive little value from having a feature to help me recover from my own poor planning in the design and\or implementation of my DDL.
--
Regards, Chuck
--
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.
midrange.com
