On Apr 8, 2005, at 3:37 PM, Joel Fradkin wrote:
I don't think my clients would like me to aprox as it is a count of their
records. What I plan on doing assuming I can get all my other problems fixed
(as mentioned I am going to try and get paid help to see if I goofed it up
some where) is make the count a button, so they don't wait everytime, but
can choose to wait if need be, maybe I can store the last count with a count
on day for the generic search it defaults to, and just have them do a count
on demand if they have a specific query. Our screens have several criteria
fields in each application.
Here is an interface idea I'm working on for displaying query results in PostgreSQL. Maybe it will work for you if your connection method does not prevent you from using cursors. I create a cursor an then fetch the first 1000 rows. The status display has 4 paging buttons, something like this:
|< < rows 1 - 1000 of ? > >|
The user can hit the "next" button to get the next 1000. If less than 1000 are fetched the ? is replaced with the actual count. They can press the "last" button to move to the end of the cursor and get the actual count if they need it. So here the initial query should be fast, the user can get the count if they need it, and you don't have to re-query using limit and offset.
The problem I'm looking into now (which I just posted on the general list) is I don't see a way to get the table and column information from a cursor. If I fetch from a cursor, the table OID and column number values are 0 in the row description. If I execute the same query directly without a cursor, the row description has the correct values for table OID and column number.
John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
