We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Generate alters for tables with Lobs without providing ddl of auxiliary table
This idea results from Case TS005582671.
the problem there is, that admintool-compare cannot generate reasonable WSL for altering a table that contains a lob-column. Actually the create-auxiliary-table-statement must also be provided, so that the correct WSL is created.
the requirement therfore is, not to have to provide the auxiliary-table-DDL in such a case.
This is the last comment in the case:
I have been discussing this issue with Development. Unfortunately, it is not an easy issue to resolve immediately. We are asking, therefore, whether, you would be willing to submit an AHA, for the following reasons:
We understand that you are generating your DDL using a different application based on objects that have been changed, and not taking into account Admin Tool DDL dependencies (which is understandable). In order to generate the ALTER for this scenario (no auxiliary table on the source), we would need to remove the DDL dependency on the source side. In addition, this would require a change in Compare's behavior. Instead of dropping and recreating the base table (which would also drop and implicitly generate a new auxiliary table), now we would go through with the alter to the base table and leave the auxiliary table alone.
Further, we need to be able to determine what kinds of ALTERs are doable, given only the information of the base table. We run into scoping issues if we try to minimize the solution just to this simple ALTER scenario, because there could be other alters to the table as well. So this would not be a straightforward fix either to code or to test in QA.
I hope that the above is clear. Please let us know if you have any questions, and please let us know if you are willing to submit an AHA idea.
Do not place IBM confidential, company confidential, or personal information into any field.