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.
"Brian Henry" <br******@adelphia.net> wrote in message
news:eM**************@TK2MSFTNGP09.phx.gbl...
I'm sorry but the disconnected archatecture doesn't work in the case of
the app i'm createing. I need a constant connection, because the information
is time sensative and can not wait for someone to push the data adapter's
update information to the database server... so i have to keep the
information constantly moveing in a connected state.. I just need to be
able to tell when the connection is bussy with a query, I thought putting a
"Bussy" text in the status bar would be nice so that the people can tell
if it is bussy on a big query. (we do very large queries, because this is a
very large insurance data processing application)
"Pavel KOHOUT" <ko****@advantages.cz> wrote in message
news:Oo****************@TK2MSFTNGP09.phx.gbl... hi,
try keep you connections closed, because ado.net opens connections
automatically (at least datadapters). so then just handle stat changing
event of your connections...
pavel
"Brian Henry" <br******@adelphia.net> píše v diskusním příspěvku
news:#u**************@TK2MSFTNGP11.phx.gbl... is there a way to tell when the database connection is retrieveing
data? i saw the connectionstate.fetching enumerated value, but of course it's not implemented yet... is there another way to do this? thanks!
