I don't know whether this is related to that current issue with authenticated databases and current builds:
I'm trying to unload a v10 OEM database with v18.104.22.1681 (brand new, yes), and I get a misleading error with SQLCODE -1020: "Cannot use log file ... since it is shorter than expected".
However, the log is just fine (and the database runs successfully as a SQL Remote remote), and unloading with other current versions (22.214.171.12401 and 126.96.36.1998) is successful, too. That might give a clue that the problem is not related to the cited FAQ, as those versions are affected by that issue, as well.
Unloading other databases seems to work with 188.8.131.521, so I don't think this is a general issue. (And it does not depend on whether option "-up" is used or not, the only additional option I'm using compared to unloading with v12/v16.)
FWIW, I tried to add the according connection_authentication string for DBUNLOAD via the InitString connection parameter but that seems to be unrecognized by DBUNLOAD (telling - translated - "Invalid or missing keyword after InitString"). However, as the current v12/v16 are able to unload from that database I don't think it's related to the missing authentication...
asked 02 Sep '15, 09:01
This issue has not been fixed in Engineering Case #789369. The problem relates to decryption of a simply encrypted transaction log file created in pre-v17. This has now been fixed and will be available in a future update to v17 (build 1271 or later).
hmmm . . .
Sounds like we would need to see the database and transaction log to debug this further.
It is likely to be self-correcting if you backup and rename the current transaction log (possibly with V17 dbeng17) if that helps any.
answered 02 Sep '15, 17:22
Nick Elson S...