FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il mar, 2004-01-06 alle 07:34, James K. Lowden ha scritto:
> On Mon, 05 Jan 2004, Steven Orton <sorton9999 AT usa.net> wrote:
> > 
> >   oh man....that is unfortunate :(  it would make my life a hell of a
> >   lot
> > easier if i could get a multirow resultset and basically search through
> > the same set multiple times.  so basically, if i want to search through
> > the set again, i have to dump the old and get a new?  i guess that's why
> > the big boys are getting buku $$$$$, ehhh?
> 
> At the risk of making a virtue of necessity, can I offer some advice? 
> You're not so bad off as you think.  
> 
> Database libraries include a lot of fanciness passed off as features, and
> in fact to someone writing applications in C they must look pretty nice. 
> To someone writing applications in C, I guess flint and steel look pretty
> advanced.  
> 
> But you're using C++, which means you have STL, which is a far far better
> thing than any ODBC cursor feature.  You have to iterate over the result
> set anyway, so why not store your rows as a std::set?  Then you can pick
> them out any way you like.  
> 
> I never really learned how to program cursors and "for browse" operations.
>  In 10 years, I guess I've opened three cursors.  Everytime I'm tempted, I
> get bogged down in the unhealthy details, and find that a T-SQL loop or
> STL container is really the better answer.  
> 
> Define a class for your row, override operator[]() and operator<(), and
> live longer.  You and your code will be happier and better looking.  
> 

Some consideration:
- in ADO.NET (the new ugly library from MS) do not support server side
cursors !!! This means that all rows are cached on client !!! MS state
itself that server side cursors under mssql do not outperform as good as
oracle...
- I had an application that needs to do a select and update this
recordset a row at a time. I used server side cursor and I gain a big
performance boost using it... Keep in mind that using a lot of server
side cursor can consume a lot of space in transaction log and server
need to cache your recordset; if you use it just for reading it's a good
idea to cache it on client...

freddy77