| From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> | 
|---|---|
| To: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> | 
| Cc: | "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: ODBC and inappropriate select * | 
| Date: | 2005-09-01 20:21:46 | 
| Message-ID: | 200509011321.46171.scrawford@pinpointresearch.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
> Is that select * being used to COUNT the number of rows?  If so,
> then do a "select count(*)" which will take the db engine about as
> long, but it won't need to transfer the data across.
Beats me. WE are not requesting a "select *" at all in the VB code. We 
are selecting and updating the rows we want to select and update via 
the appropriate "where" information.
Somewhere in the black box that is VB/BusinessObjects/ODBC something 
is deciding that a "select *" is necessary for reasons unknown and 
then choking on (well, not actually choking but digesting slowly) the 
data returned.
I'm just trying to find out if anyone has seen this problem and is it 
something inherent in VB, BusinessObjects or ODBC? In other words, is 
it something we can fix or do we need to set aside time to rewrite 
the app in a language that doesn't have these problems?
Cheers,
Steve
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Reid Thompson | 2005-09-01 20:39:33 | Re: ECPG examples... | 
| Previous Message | Tom Lane | 2005-09-01 20:12:27 | Re: Check if SELECT is granted |