tag:blogger.com,1999:blog-18371456.post1232787743675026134..comments2024-03-16T06:32:31.036-05:00Comments on The Db2 Portal Blog: Reordered Row Format [DB2 9 for z/OS]Craig S. Mullinshttp://www.blogger.com/profile/17077237739217901780noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-18371456.post-22953660680843190932011-09-29T12:03:44.045-05:002011-09-29T12:03:44.045-05:00It is possible, though not necessarily recommended...It is possible, though not necessarily recommended, to switch off RRF using a hidden DSNZPARM (SPRMRRF)<br /><br />Please note, though, that SELECT * will not changes the order of the columns retrieved regardless of BRF or RRF. Even though the columns change location as stored on disk, they are still returned to the program in the order of the DDL (DCLGEN).Craig S. Mullinshttps://www.blogger.com/profile/17077237739217901780noreply@blogger.comtag:blogger.com,1999:blog-18371456.post-52213791007496719812011-09-29T09:55:57.754-05:002011-09-29T09:55:57.754-05:00Can this "feature" be turned off?
Seems ...Can this "feature" be turned off?<br />Seems to me that any application coded with Select * will get "interesting" results, until they can correct this poor coding practice.<br />I feel a bit uneasy with DB2 moving columns around in a table...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-18371456.post-8820855806057454922009-04-16T09:49:00.000-05:002009-04-16T09:49:00.000-05:00It seems, the parsing of DB2 log UNDO/REDO records...It seems, the parsing of DB2 log UNDO/REDO records is problematic with the RRF.<br />Let's assume, there is a table including 4 columns with several varying length among them. <br />After insertion (SQL INSERT), a DB2log UNDO/REDO record containing these 4 columns (DATA CAPTURE CHANGES has been specified) will be created. <br />Let's add now one more fixed length column (ALTER TABLE ADD) <br />and then delete the inserted row -the new UNDO/REDO record still includes 4 columns in spite of the fact that the table has been altered. <br />When we do the same actions (insertion/deletion) after altering the table, the relative UNDO/REDO records DO reflect the new (altered) table format and contain all 5 columns. <br />There is not any indicator in log records, how much columns they include, no a number of columns, nor a length of a fixed part. <br />The parsing can not be done correctly when there are variable length columns and an added one is fixed (is added at the middle of the record). <br />This problem does not exist in BRF tables where new columns are added at the end of a row (ENDO/REDO record).eliginhttps://www.blogger.com/profile/12192260863225248669noreply@blogger.com