home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / sybase / 638 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.2 KB  |  51 lines
  1. Newsgroups: comp.databases.sybase
  2. Path: sparky!uunet!tekbspa!tssgate!esh
  3. From: esh@prague.tss.com (Edward S. Hirgelt)
  4. Subject: Re: possible FAQ Question...
  5. In-Reply-To: ecr2@ellis.uchicago.edu's message of Fri, 8 Jan 1993 15:53:56 GMT
  6. Message-ID: <ESH.93Jan8104313@prague.tss.com>
  7. Sender: news@tss.com (USENET Network News)
  8. Organization: Teknekron Software Systems, Inc.
  9. References: <1993Jan8.155356.19950@midway.uchicago.edu>
  10. Date: Fri, 8 Jan 1993 18:43:13 GMT
  11. Lines: 38
  12.  
  13.  
  14. On Fri, 8 Jan 1993 15:53:56 GMT,
  15. ecr2@ellis.uchicago.edu (corprew reed) said:
  16.  
  17.         I was wondering if it was possible to find out the number of
  18.     rows that a query will return before accessing the data without using
  19.     'count(.*)' with select.  I have a large query that takes a while to
  20.     execute, and I'm hoping to keep my application reasonably interactive
  21.     by not executing it once for the count and once for the data.
  22.  
  23. As far as I know this isn't possible although very desirable. Think
  24. about it this way, the server can't know what rows will match the where
  25. clause until it actually qualifies them. So it must evaluate your query
  26. to know how many rows. Since it is qualifying the rows, it immediately
  27. starts sending them off to you as soon as it can.
  28.  
  29. This is what you really want. If there are 500,000 rows that match a
  30. complicated query you want to start seeing rows as soon as possible. The
  31. user sitting behind the application is not going to be pleased waiting
  32. for the 500,000 row to be qualified before he sees the first. This is
  33. the reason why you don't want to do the select count(*) now. It is also
  34. the reason that rows are returned immediately upon being qualified.
  35.  
  36. I've written applications where I've done the count(*) first to inform
  37. the user what is happening. However, these was generally done for small
  38. tables where the user got to chose some information. For big results or
  39. small results with complicated queries it is a lot messier.
  40.  
  41. The best you can do is keep track of where you are in the list, enable
  42. row buffering in dblib, implement your own row buffering,  and wait for
  43. cursors (would they really help though). 
  44.  
  45. Good luck,
  46. Ed
  47. --
  48. Ex vitio alterius    |Ed Hirgelt            |esh@tss.com
  49. sapiens emendat suum.    |Teknekron Software Systems, Inc|
  50. (Publilius Syrus)    |Palo Alto, Ca.            |
  51.