On Thu, 2005-09-01 at 15:21, Steve Crawford wrote:
> > 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?
This sounds like the way access behaves, or at least used to, when using
a database other than MSSQL server. It's quite likely that whatever
VB/BusinessObjects is doing was written by the same poor sap who wrote
access's methods at the time, and just carried over that same brain dead
logic.
I'd check for updates to VB/WebObjects to see if there's a known problem
and / or fix with it.
I doubt it's ODBC in general, I've used that before, without this
problem, including on MS boxes. But you may have an old version that
was written, again, by the same guy who wrote access. Then who knows?