• Print |
• E-mail  |
• Bookmark

The problem can occur when there is an overlap in reading the rows from
two different tables by PROC SQL.  If PROC SQL opens one table and reads
a row from the table and then opens another table to read it's rows, the
open for these tables are both on the same connection to DB2.  The
problem is a result in the fact that the DB2 engine issues a COMMIT
during the open processing. The effect this has is that when the second
open is done, the commit is triggering the first tables' cursor to be
marked as invalid. So when SAS goes back to retrieve another row from
the first table the result set is being regenerated. Since the result
set is regenerated, the results might not be returned in the same order
as it was done previously. The rows that SAS thinks it has already
processed are skipped so any rows that ended up at the top that were
previously at the bottom are skipped and any rows at the top that were
previously processed and now are at the bottom of the result set are
processed once again.


A fix for SAS 9.1.3 (9.1 TS1M3) for this issue is available at:

http://www.sas.com/techsup/download/hotfix/e9_sbcs_prod_list.html#013519

For customers running SAS with Asian Language Support (DBCS), this
fix should be downloaded from:

http://www.sas.com/techsup/download/hotfix/e9_dbcs_prod_list.html#013519

Operating System and Release Information

A fix for SAS 9.1.3 (9.1 TS1M3) for this issue is available at:

A fix for SAS 9.1.3 (9.1 TS1M3) with Asian Language Support (DBCS) for this issue is available at :