× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.ibm.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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.