Bidirectional cursor navigation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Is there any class supports bidirectional cursor in the ADO.NEt framework? I
was looking some of the samples and only talks about SqlDataReader (forward
only cursor).

Or is there any way i can make use of database cursors in my dotnet
application to navigate the records from a table.?

Hari
 
So that mean if i need to navigate a largeset of rows in my application, do i
have to write paging/caching logic in my application? I couldn't find the
Dataset classes in ADO.NET support caching/paging? Please suggest me some
alternative for the following problem :

- table contains 50,000 rows
- the sample query is : select * from table1 where crietria1 and criteria2
9may returns 40,000 rows
- My UI controls need to navigate forward/backward through records, but i
don't want to load the 40,000 rows in memory at a time(per say using dataset
or datatable)

I could find in ado recordset supports to do this type of scenario. bu i
couldn't find similar with ado.net classes. (means with new framework do i
need to write more code???)

Hari
 
Its standalone application with MSDE2000 server.
Also could you clarify me, is there any reason , ado.NET is not implemented
this paging/caching logic in the dataset classes? since ado recordset takes
care of this client side memory management, so i did a bad decision moving to
ado.net???

Hari
 
I think if the database client app and server is in the system, is it good
not to have disconnect way of accessing the data? Hope if some of the classes
are with ado.net it would be much easier for us???

Thanks Sahil

Hari
 
I think if the database client app and server is in the system, is it good
not to have disconnect way of accessing the data?
Click to expand...

I disagree. Continously connected architectures are a recipe for disaster.
Those architectures donot scale and cause a whole lot of other issues.

If still you insisted on doing connected architecture, including server side
cursors, you could still use SqlCommand.ExecuteNonQuery.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
 
Ah, I have to disagree here. There are plenty of success stories with
"connected" architectures. Remember that most applications written before
the wonders of the web implemented connected architectures. It's simply a
matter of managing the data in a different way. Not every application needs
to scale to 5000 or 5 million users. Consider that the vast majority of
multi user applications support fewer than 200 users--often far fewer. SQL
Server (using connected architectures) can support thousands of users (we
did so with a 386/33 box with 4MB). These application sometimes created
server-side cursors but these did not span entire tables as some would have
you do today with disconnected architectures. Up until ADO.NET, ADO classic
supported server-side cursors very nicely. As a matter of fact, you can
still implement them today using the ANSI SQL CREATE CURSOR syntax--I'll
show how to do this at my DevTeach workshop in Montreal in June.

Sure, any scalable architectures (including connected or disconnected or web
services) requires discipline and applications that don't bring the server,
web or client to its knees doing dumb stuff.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Okay, I agree with that - not every app has the need to scale to crazy
proportions.

Also, ADO.NET does not limit you to disconnected architectures. As you point
out, you can still do server side cursors using ADO.NET - just wrap it in a
SqlCommand (right?).

But when someone says ADO classic is better than ADO.NET - well .. !!! :-)
(Okay you can really argue ANYTHING, but c'mon !!)

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/
 
ADO classic is different. It has more features than ADO.NET in some
respects. It has async operations (now) (including async connections), it
has server-side AND client-side cursors, control over concurrency and lots
of people know how to use it. ADO.NET has other features and is still
evolving. It's lighter, faster and must be restricted to OLE DB provider
issues or DLL hell. It's different and not as many people know how to use
it. It's my (our) job to make ADO.NET easier for the ADOc developers to use
and migrate their applications.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Back
Top