Log-In to post
Contact Support on Twitter
The better a problem is described, the better the assistance tends to be.
In order to better assist with your issue at hand, please include the following information in your initial post:
- Product, Version, and relevant environment details.
- Include a screenshot of the problem
- Describe the problem fully. What result was expected?
- Can the issue be created on demand or is it intermittent?
- If the problem can be generated faithfully, what are the exact steps to recreate the problem?
- Any other pertinent information (see below)
Create Support Bundles
You can create a support bundle and send it to Dell Support or to the Toad for IBM DB2 community Web site (peer-to-peer support). The support bundle provides information (about your application and the database) that is used to help troubleshoot problems.
Select Help | Support Bundle. It may take time for Toad to generate the support bundle depending on your system configuration.
Create Support Bundle for a SQL Query Issue
If your issue is a SQL query issue, it is helpful if additional log files are included in the support bundle. These log files are automatically included if you generate a support bundle immediately after executing the query in either the Editor or Query Builder.
To create a support bundle for a SQL query issue
1. In the Editor or Query Builder, reproduce the error or issue.
2. After reproducing the error, immediately select Help | Support Bundle to generate a support bundle.
3. Toad asks if you want to log the row count for each table used in the query. If you select Yes, Toad determines the size of each table used in the query. This adds additional time to the generation process, but also provides additional information about your issue.
4. When Toad is finished generating the support bundle attach log.
Note: For best results, always send the entire support bundle. This provides Support with the most information about your issue and aids the troubleshooting process.
*Note: Please refrain from including private data in your posts
Be as thorough as you can with the provided info. We will reply to you as quick as possible. We are glad to assist you
Latest Release Information:
This announcement includes information on our latest releases, links to our downloads and documentation and overview of new features. This way you can stay as informed as possible:
- What’s New Section (why they would want to pay attention to this new version)
- Link to Download & Documentation
- Link to Trial (if applicable)
- Overview of new feature(s) (with link to the release notes)
Top 5 Knowledge Base Articles:
On this post, you can find our top trending knowledge articles that other customers are inquiring about and popular solutions.
This month’s Top Knowledge Base Articles
Feel free to browse them. Remember to sign in to your account to view.
We are just scratching the surface around database version control and am trying to get an idea how Toad for DB2 LUW plays in regard to that. Looking for both positive and negative feedback to get at least a general idea of how people are using this functionality.
We just posted the Toad DB2 v6.5 Beta 126.96.36.199.
That beta drop contains several fixes and extends the beta expiration into December, 2017.This installer now has a new option that can prohibit users from saving their connection profile passwords.Please try out this new drop and let us know what you think.
You can download this new beta at:
I have just upgraded to 6.5 and I am getting a problem which I didn't get in 6.1.
When I put statements such as :
DECLARE v_current INT DEFAULT 0;
in to the editor I get the "red star" syntax error highlight, see below
However, if I remove the semi colon from the first line, the second line no longer errors:
I'm sure this is a configuration issue, but I can't see which option to change to fix this problem.
Look forward to hearing from you.
When comparing data between two schemas, if one of the fields is a CLOB and there is a difference in aonther field, the resulting update script includes an update of the CLOB field that results in erroneous data.
The update stataement does not replace the data with the data from the source but it adds part of the data to what already exists.
This behavior is similar to what I complained about here:
Whereas that was anuisance reaulting in the way I used the resulting script, the issue I have here is clearly a BUG.