×
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.
Yep, understood. But adding a new logical file or index is just one scenario.
That's good to know about adding fields at the end of the table. However I've seen scenarios where people feel the new fields have to be in-the-right-place in the DDS.
What you described should minimize the possibility of level checks.
Does it work the same with DDL driven tables if you do an alter table ?
I just know in the past I've been bitten by level checks so am trying to anticipate this possibility ahead of time by making sure they catch/recompile all related programs if there is a table change.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
-----------------------------
message: 3
date: Wed, 24 Nov 2021 16:16:41 +0000
from: Alan Shore via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>
subject: RE: Deploying DB2 Table Changes
Adding a new logical or index will have NO direct bearing on the physical file In this instance - there is no need to make a copy of the physical file Adding a new field - as long as it is at the end of the record layout. There should be no need to make a copy of the file Adding a new field - NOT at the end of the record layout, but in between 2 existing fields - the question I would ask is - why is it being done this way. If it DOES need to be changed this way - then as a precaution, I would make a copy of the file Changing an existing field - changing the size, changing from an alpha to a numeric field (for whatever reason), then as a precaution, I would make a copy of the file
midrange.com
