Using ADO.NET in a Connected not Disconnected Fashion

[Steve Le Monnier]

The ADO.NET DataSet is idea for application development, especially if you
need disconnected data. DataReader objects are great in the connected
environment but are forward only. What do you do when you want a connected
application but need the ability scroll forward and backward within the
result set.

What I'm trying to achieve is to build an application that has navigation
buttons, thus allowing the user to step forward or backward within a table.
If I use a DataSet the information is cached locally within the DataSet, but
changes to the data on the server are not reflected instantly unless the
user refreshes the data.

The alternative is to use a DataReader, but this only allows stepping
through records in a forward only direction.

What tools or techniques exist to allow two apps to step through records in
any direction, but if user A makes a data change User B sees that change as
soon as they get to the record when they reach it via a move next operation.

Any tips, techniques or articles gratefully received.

Steve

 

[Alvin Bruney [Microsoft MVP]]

As you rightly pointed out, the model has changed so that this is no longer
possible. In fact, i'd argue that code like that just should not be written
anymore because it defeats the purpose of the architecture. However, the
model is flexible enough so that you can program around the obstacle.

One approach is to catch the update to the dataset via an event and then
immediately turn around and fire the update to the underlying datastore. You
can either catch the event or call the dataset.getchanges() function to
retrieve the changed rows.

You do see the problem though? This is not a scalable approach because it
creates too much traffic in high concurrency situations.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc

 

[Steve Le Monnier]

Thanks Alvin

I've played with the GetChanges on DataSets (which is really cool) and this
helps ensure my local DataSet being used by User A is updated, the problem I
have is that User B with their DataSet is totally unaware that the
information they are stepping through is now out of data, as they are
steping through a locally cached DataSet.

How do I allow users to step forward and backward through data, but ensure
all users see the very most recent data available.

Cheers

Steve

As you rightly pointed out, the model has changed so that this is no
longer possible. In fact, i'd argue that code like that just should not be
written anymore because it defeats the purpose of the architecture.
However, the model is flexible enough so that you can program around the
obstacle.

One approach is to catch the update to the dataset via an event and then
immediately turn around and fire the update to the underlying datastore.
You can either catch the event or call the dataset.getchanges() function
to retrieve the changed rows.

You do see the problem though? This is not a scalable approach because it
creates too much traffic in high concurrency situations.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------

The ADO.NET DataSet is idea for application development, especially if
you need disconnected data. DataReader objects are great in the connected
environment but are forward only. What do you do when you want a
connected application but need the ability scroll forward and backward
within the result set.

What I'm trying to achieve is to build an application that has navigation
buttons, thus allowing the user to step forward or backward within a
table. If I use a DataSet the information is cached locally within the
DataSet, but changes to the data on the server are not reflected
instantly unless the user refreshes the data.

The alternative is to use a DataReader, but this only allows stepping
through records in a forward only direction.

What tools or techniques exist to allow two apps to step through records
in any direction, but if user A makes a data change User B sees that
change as soon as they get to the record when they reach it via a move
next operation.

Any tips, techniques or articles gratefully received.

Steve

 

[Alvin Bruney [Microsoft MVP]]

There are a couple of patterns for this. One centers around having user B
actually update the stale data. At that point, you indicate to the user that
rows 5, 6, 8 have been changed, display the changes and ask the user if they
want to proceed with the requested change.

Another approach is the bury-your-head-in-the-sand approach. Let the user
update the stale data since the premise is that fresh data is going to be
inserted anyway.

you can also set a global flag whenever you update the datasource. If the
flag is dirty, you discard the contents of the dataset ( it means that a
user updated) and pull data from the datasource instead for all users
requesting data, then reset the flag.

Another pattern involves writing a database trigger that writes a file when
rows are inserted to the database. Then, you set a cache dependency on the
file to reload the cache with a new dataset. They each have their
disadvantages.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------

Thanks Alvin

I've played with the GetChanges on DataSets (which is really cool) and
this helps ensure my local DataSet being used by User A is updated, the
problem I have is that User B with their DataSet is totally unaware that
the information they are stepping through is now out of data, as they are
steping through a locally cached DataSet.

How do I allow users to step forward and backward through data, but ensure
all users see the very most recent data available.

Cheers

Steve

As you rightly pointed out, the model has changed so that this is no
longer possible. In fact, i'd argue that code like that just should not
be written anymore because it defeats the purpose of the architecture.
However, the model is flexible enough so that you can program around the
obstacle.

One approach is to catch the update to the dataset via an event and then
immediately turn around and fire the update to the underlying datastore.
You can either catch the event or call the dataset.getchanges() function
to retrieve the changed rows.

You do see the problem though? This is not a scalable approach because it
creates too much traffic in high concurrency situations.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------

The ADO.NET DataSet is idea for application development, especially if
you need disconnected data. DataReader objects are great in the
connected environment but are forward only. What do you do when you want
a connected application but need the ability scroll forward and backward
within the result set.

What I'm trying to achieve is to build an application that has
navigation buttons, thus allowing the user to step forward or backward
within a table. If I use a DataSet the information is cached locally
within the DataSet, but changes to the data on the server are not
reflected instantly unless the user refreshes the data.

The alternative is to use a DataReader, but this only allows stepping
through records in a forward only direction.

What tools or techniques exist to allow two apps to step through records
in any direction, but if user A makes a data change User B sees that
change as soon as they get to the record when they reach it via a move
next operation.

Any tips, techniques or articles gratefully received.

Steve

 

[Steve Le Monnier]

Thanks Alvin

I'm going to spend some time research the possibility of having a database
flag which will indicate how old the data in each table is, Using the
SQLHelper execute scalar method I should be able to retrieve this flag or
time value efficiently and then update the local dataset(s).

This seems the best way of resolving my problem... many thanks for the idea.

Cheers

Steve