This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
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:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
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
Specific links you will want to bookmark for future use
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.