SQL0407N occurs when binding files from older version (DB2 v7.2 @ OS/2)

[helmut]

Hi,

when binding V2 or V6 bind files to a V7 database, we get a SQL0407N
on a system table (SYSIBM.SYSPLANDEP).

The Database versions are:
- V7.2, FP12 WR21336 on the server
- V2.1 or V6.1 (no FP) on the development system

In case, it is important:
The database was migrated before from 2.1 -> 6.1 -> 7.2

Any ideas?
Does IBM garantuee compatibility for this scenario?

Thanx,
Helmut

[Knut Stolze]

helmut wrote:

Hi,

when binding V2 or V6 bind files to a V7 database, we get a SQL0407N
on a system table (SYSIBM.SYSPLANDEP).

The Database versions are:
- V7.2, FP12 WR21336 on the server
- V2.1 or V6.1 (no FP) on the development system

In case, it is important:
The database was migrated before from 2.1 -> 6.1 -> 7.2

Any ideas?
Does IBM garantuee compatibility for this scenario?

What's the SQL statement from the bind file that tries to access
SYSIBM.SYSPLANDEP?
If your application tried to access that table directly, then the error is
your own problem. You should stick to the documented and supported SYSCAT
views because IBM tries to ensure backward compatibility for these views.

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

[helmut]

Knut Stolze <st****@de.ibm.com> wrote in message news:<cf**********@fsuj29.rz.uni-jena.de>...

helmut wrote:

Hi,

when binding V2 or V6 bind files to a V7 database, we get a SQL0407N
on a system table (SYSIBM.SYSPLANDEP).

The Database versions are:
- V7.2, FP12 WR21336 on the server
- V2.1 or V6.1 (no FP) on the development system

In case, it is important:
The database was migrated before from 2.1 -> 6.1 -> 7.2

Any ideas?
Does IBM garantuee compatibility for this scenario?

What's the SQL statement from the bind file that tries to access
SYSIBM.SYSPLANDEP?
If your application tried to access that table directly, then the error is
your own problem. You should stick to the documented and supported SYSCAT
views because IBM tries to ensure backward compatibility for these views.

The application does _not_ access that table directly. The SQL
statements referenced by the error message for the 3 bind files are
- EXEC SQL SELECT MAX(LFDNR)
INTO :maxlfdnr:maxlfdnrIND
FROM QDBADM.Qdzsch;
- EXEC SQL UPDATE QDBADM.QDZSCH SET
AUFTRNR = :auftrnr:auftrnrIND,
AUFTRPOS = :auftrpos:auftrposIND,
...
WHERE LFDNR = :lfdnr;
- EXEC SQL UPDATE QDBADM.QDIFPI SET
AUFTRNR = :auftrnr:auftrnrIND,
AUFTRPOS = :auftrpos:auftrposIND,
...
WHERE LFDNR = :lfdnr;
respectivly.

[Jan M. Nelken]

helmut wrote:

The application does _not_ access that table directly. The SQL
statements referenced by the error message for the 3 bind files are
- EXEC SQL SELECT MAX(LFDNR)
INTO :maxlfdnr:maxlfdnrIND
FROM QDBADM.Qdzsch;
- EXEC SQL UPDATE QDBADM.QDZSCH SET
AUFTRNR = :auftrnr:auftrnrIND,
AUFTRPOS = :auftrpos:auftrposIND,
...
WHERE LFDNR = :lfdnr;
- EXEC SQL UPDATE QDBADM.QDIFPI SET
AUFTRNR = :auftrnr:auftrnrIND,
AUFTRPOS = :auftrpos:auftrposIND,
...
WHERE LFDNR = :lfdnr;
respectivly.

Helmut,

Please provide me with a complete example of application code and matching
bind file created under V6 which is causing error in V7.

This is only scenario which I believe *should* be working. Any examples from
V2 have only historical value.

V7 is sstill supported (until Semptember 30, 2004) - so theoretically speaking
application compiled under V6 should be working under V7.
It is quite possible, that FP for V6 should be applied (latest was FP11).

Jan M. Nelken
(jasinek at attglobal dot net)