Strange problem. Need help!

  • Thread starter Thread starter Ken Varn
  • Start date Start date
K

Ken Varn

I have a really wired thing going on here and I can't seem to figure out
what is wrong. I have a managed C++ application that is using ADO.NET on an
Access database.

Here is the steps that I am taking that are causing a problem:

1. I open a OleDBConnection to the database
2. I create an OLeDBDataAdapter to read in a table.
3. I read the table into a DataSet with the data adapter in step 2.
4. I modify several rows in the DataSet with some updated values (basically
setting a Yes/No column to 1).
5. I update the database using the data adapter.
6. I close the connection.
7. At this point, I check the database with Access and confirm that the
changes have been made.
8. Next, in another portion of code, I open a new connection to the same
database.
9. I read several tables into a DataSet, including the table modified in
step 4. I am using a where clause on the command object to only get the
rows that have the column (used in step 4) set to 1.
10. At this point, I check the dataset contents, and all but 1 of the rows
is read back, even though the missing row should have been included with the
query.
11. Now comes the weird part, If I clear the dataset, and read it again
using the same command string, then all of my data is read the way I expect.


I hope someone can decipher all of this and make some sense out of it and
tell me what is wrong. I am getting really frustrated here because I know
that this is a simple operation. I am fairly familiar with ADO.NET and this
seems like it should just work and it is messing with my mind.

Is there some bug in the Jet 4 DB engine or in .NET 1.1 that would be
causing this?



--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
 
It would be useful to have a small reproduceable case.

A suggestion I have is to switch databases, but use the same code. So use
SQL Server or MSDE, use SqlClient, keep all the table structures and queries
the same, and try to run the code then.

If the issue disappears, then it may be a bug. If the issue still exists, it
is probably an issue with the code itself. But you can try use the Profiler
tool (if it's SQL Server) to see exactly what statements are being executed
against the database in hopes that holds a clue.
 
I finally think I found it!

I was looking at my code and realized that I was not calling Close() on the
connection. Instead, I was calling Clone(). My eyes were deceiving me. I
let intellisense get the better of me in this case.

Sorry about that.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
Marina said:
It would be useful to have a small reproduceable case.

A suggestion I have is to switch databases, but use the same code. So use
SQL Server or MSDE, use SqlClient, keep all the table structures and queries
the same, and try to run the code then.

If the issue disappears, then it may be a bug. If the issue still exists, it
is probably an issue with the code itself. But you can try use the Profiler
tool (if it's SQL Server) to see exactly what statements are being executed
against the database in hopes that holds a clue.
Click to expand...
 
Back
Top