Re: VB.NET ADO Recordset DataGridView and Access not in sync w/oth
- From: Jim Crist <JimCrist@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Apr 2008 06:14:01 -0700
Thanks much, I agree. I started rewriting it last nite before I saw your
post. In fact, I had it mostly written in ADO.NET BEFORE I decided Recordset
would be simpler. Oh well, thanks for the push...
"Bob Barrows [MVP]" wrote:
Jim Crist wrote:.
I have a very small, simple database in Access. I have it bound to a
DataGridView in VB.NET. I can add, change and delete records via the
DataGridView, and the changes are reflected in Access. A different
section of code (aka Checking Code) reads the database and under
certain conditions it will change a field in the database. I thought
everything was working pretty well, until I realized that changes
made via the DataGridView weren't being detected by the Checking Code.
Since this is a simple database, I opted to use a ADO.NET RecordSet:
That's an oxymoron: ADO.Net does not have a recordset object. You are using
a classic COM ADODB connection and recordset via Interop, and there really
is no reason to be doing so, simple database or otherwise. You're in the
..Net world so stick with the .Net objects: use an oledatareader to retrieve
data, and an olecommand object to perform your updates (it is usually bad
practice to maintain data with a cursor - DML SQL - update, insert and
delete, is so much more efficient) so you don't have to open another
connection to the database. You are preventing session pooling from working
to your best advantage by doing using different connections.
What you are undoubtedly falling victim to is Jet's delayed-write
optimization. Jet caches writes to the database for some period of time to
improve performance. See
http://support.microsoft.com/kb/200300
and (not so relevant, but illuminating):
http://support.microsoft.com/?kbid=240317
Having said all that, I do need to include my canned reply (your question
partially concerned ADODB which is ontopic here so it fell into a gray
area):
There was no way for you to know it (except maybe by browsing through some
of the previous questions in this newsgroup before posting yours - always a
recommended practice) , but this is a classic ADO newsgroup. ADO.Net bears
very little resemblance to classic ADO so, while you may be lucky enough to
find a dotnet-knowledgeable person here who can answer your question, you
can eliminate the luck factor by posting your question to a group where
those dotnet-knowledgeable people hang out. I suggest
microsoft.public.dotnet.framework.adonet.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
- References:
- VB.NET ADO Recordset DataGridView and Access not in sync w/other c
- From: Jim Crist
- Re: VB.NET ADO Recordset DataGridView and Access not in sync w/other c
- From: Bob Barrows [MVP]
- VB.NET ADO Recordset DataGridView and Access not in sync w/other c
- Prev by Date: Re: VB.NET ADO Recordset DataGridView and Access not in sync w/other c
- Next by Date: Create a multi-column primary key from C++
- Previous by thread: Re: VB.NET ADO Recordset DataGridView and Access not in sync w/other c
- Next by thread: Create a multi-column primary key from C++
- Index(es):
Relevant Pages
|
|
