When you get a result set with more than 2000 rows (or whatever you have your limit set to), the prompt doesn’t tell you how many rows you are going to get if you click OK to continue. This makes it difficult to decide if you want to bypass the limit.
Then there is no way to stop the results from coming back if you opt to get all results. This will be a big problem is hundreds of millions of rows are returned.
Finally, even if I do stop the result at 2000 rows, the SQL history shows 2000 rows, rather than the actual row count (like I get in SQL Assistant). I could use the row count button, but the count is not captured for future reference.
Are there any ways to solve this?
We had to change the result set processing to NOT get the row count during this flow. The problem was that when calling the JDBC driver to reposition to the last row (which is how you get the row count) it could take a very long time and was not interruptable, giving the appearance that things were hung. The menu option to get the row count on the table (right click, Teradata>Row Count) should return the row count for the table. Is there an exception that occurs?
The menu option is working as expected. It returns the row count for a table.
What seems to not be working is when I opt to get back all of the rows (beyone the set limit), I cannot stop the retrieval like I can in SQL Assistant.
As I develop a query, I want to check row counts as I build the query by adding joins to other tables, plus see some results to make sure things look correct. Sometimes I want to see more rows than the 2000 limit. Using the history column for rowcount in SQL Assistant (where the total rows appears in the Row Count column, not the rows returned to the Answerset) as a check was easy and convenient
Since this seems to be an effect from using JDBC (slow response time to get to the last row), it sounds like the process will not be changed. Will there be any chance that ODBC will be added as a connection option?
Without this, I assume I will have to build select count(*) wrappers around my SQL. Doable but inconvenient. IMO the new tool is missing valuable functionality that was available in the old tool.
Bill, Since this is a Java based tool, there are no plans to include ODBC. We struggled with taking out the functionality of getting the row count but the affect of the long delay for large result sets was causing more distress from users. We hope there will be a better alternative from the JDBC driver in the near future.
OK, this is a big problem for me as a developer. I'd rather wait for the last row and know what I'm getting, plus have that total show up in my SQL history.
Also, any chance for this to be addressed?: there is no way to stop the results from coming back if you opt to get all results. This will be a big problem is hundreds of millions of rows are returned.
I didn't know about that restriction of the JDBC driver, that sounds really bad :-(
I always liked to know in advance how many rows will be returned, I think I'll better keep connecting using ODBC/.NET/CLI :-)
Is this a generic JDBC restriction?
@bmcclernan, The row count was previously obtained after the query had completed and returned a result set. Stopping or canceling at that point ('Yes' response to the question) would stop the retrieval of rows from the result set to be displayed in the result set viewer. But trying to cancel once you replied 'No' (keep going), you could not cancel. We have also fixed this issue in our next release so that you can cancel once it starts retrieving from the result set to be displayed in the result set viewer.
Also, the final row count in the SQL History will reflect the actual number of rows that were retrieved. With the fix, if you cancel during the display to the result set viewer, the row count will reflect the number of rows actually retrieved before it stopped.