Brian:
I'm responding to your other post when I saw this one. They are two
seperate issues so I'm addressing them seperately. You mention not being
able to wait for data to be 'Push'ed but ADO.NET doesn't push data to the
user, in either connected or disconnected methodology.
I think you may be confused by the way ADO.NET works. Having a connection
'open' doesn't mean that you are getting up to the minute data. All it
means is that you have a connection open. You mention that you can't wait
for someone to push data down from there server, but ADO.NET and the
DataAdapter are Not Push objects. You have to query the DB either way to
get that data. Moreover, just because you leave a connection open doesn't
mean anything. You could use a DataAdapter and leave your connections open
just as easily as you can with a DataReader or Command.method (although you
don't want to do this).
My point is that if you want the most up to date data, you are going to have
to query the DB constantly. This is the same whether or not you leave a
connection open or close it immediately and it's going to be the same
regardless of which model you use. Your DB won't fire another query and give
you live data just b/c the connection is open.
I would also caution you that if your data is so time sensitive that you
need to refresh it constantly, you may cause yourself some serious
Performance Killing problems by leaving your connections open. Certainly
there will be lag time between queries (at a minimum it will take x amount
of time for the query to execute and you to respond to it). there are
occassions where you have a bunch of back to back operations and leaving a
connection open makes sense but those instances are rare and even then you
should still close the connection as soon as you are done with it.
And if your app is dealing with large amounts of data, I'd really advise
rethinking the methodology here because I doubt you'll be able to have an
app that is keeping really large amounts of data constantly up to date with
many users without some serious artillery. And even then I don't think
client side UI and Processing will lend itself well here.