This portal is to open public enhancement requests against IBM Z Software products. 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).
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:
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 updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - Business Developer
For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - Business Developer
I like this RFE to be reconsidered.
Please consider the comments I added on 01 Mar 2011.
An other suggestion is to extend the capabilities of the fromTablesWhere option by having an 'orderBy', 'groupBy' and 'having' option for composing the SQL. The prepare statement then can use all options and the count(*) can only use the fromTablesWhere option.
Hello IBM_Rational_Developer,
I see your point that it would be difficult to create a generic function to omit SQL statement parts in order to reduce the original SQL statement to apply to a count(*) statement. However I think our suggestion would make a good start and will cover 90% of all problematic SQL requests.
Maybe you can create a program exit point where the programmer can implement their own algorithm for stripping the SQL. This exit point can be a function in a part of the service that won't get regenerated when recreating the service.
While we can see the value of what you are asking for, it would be very difficult to implement a generalized solution. It is the customer's customization that adds the "order by" (which makes sense on a list) to the fromTablesWhere string. It is our design to use the same string in the prepare for the SELECT COUNT(*) statement. Since we don't know what they will add, how do we know what to strip out like the ORDER BY and are there other clauses that don't work for the SELECT COUNT(*). This could be anything allowed in SQL... joins, subselects, etc...are all allowed on SELECT COUNT(*) except the ORDER BY.
We are unlikely to implement this request in the near-to-medium term.