While performing an Eclipse Product export, via wizard, the following error came up:
Cannot complete the install because of a conflicting dependency.
Software being installed: iCANgraph 1.0.0 (Lumina 1.0.0)
Only one of the following can be installed at once:
Cannot satisfy dependency:
Yes, the dependecy that could not be satisfied was not stated, so there was no clue about what was causing this export error…
There was absolutely no more error information. No export log was found, thus this useless error message was all that I had…
It took some time until I realise that the “Generate metadata repository” option was enabled, causing all this problems.
This option enables the “Provisioning platform“, commonly known as P2, which builds P2 repositories and products. It creates a plugins folders (repository\plugins) that contain the same plugins as the folders in the exported application.
My guess, since I was unnable to get suficient information to know for sure, is that the automatic resolution of dependencies between software components, one of P2 features, was not doing things properly, thus the error.
Since all that was needed was a product, the P2 information was unecessary and, obvisouly, redundant and a real trouble maker.
To solve this problem, all that was required was to disable the “Generate metadata repository” option and export the product again.
On data migration projects using BD2, sometime there are some awkward DB2/JDBC errors.
It does not matter if it is DB2 on Windows, Unix or iSeries AS/400.
Part of the problem is that the error messages come in localized, on our case in Portuguese, making the debug task a lot harder since it’s almost impossible to find decent help by searching through the error messages. The other part of the problem is that the SQL error codes sometimes are unclear.
Here’s an example of a common problem that we have in data migration projects:
com.ibm.db2.jcc.b.rg: [jcc][t4][3.50.152] Non-atomic batch failure. The batch was submitted, but at least one exception occurred
on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements.
com.ibm.db2.jcc.b.pm: Error for batch element #1: The current
transaction was rolled back because of error "-289".. SQLCODE=-1476,
[...] ERRORCODE=-4225, SQLSTATE=null
Following DB2 official documentation:
- SQLCODE=-1476 means that the current transaction was rolled back because of one of the listed errors, but none of them made much sense since none of the errors identified seem to apply.
- SQLSTATE=40506 means that the current transaction was rolled back because of an SQL error, which is basically the same as the SQLCODE above.
- ERRORCODE=-4225 means an error occurred when data was sent to a server or received from a server, which is totally useless.
The real useful information is hidden in the second error message, in the ‘transaction was rolled back because of error “-289”‘ message. The key here is the -289 error.
This error means “Unable to allocate new pages in table space“, and this is the real cause for such a big fuss.
In data migration projects it’s common some of the DB2 table spaces to run out of space. But with such an error message, the error itself is kind of hidden in the middle of the stack trace, all that is shown is a loose error code…
For the sake of the developers productivity, the cause of the error should be highlighted and perfectly visible and understood in order to be quickly identified and fixed.