Any way to disable "lazy write" in Jet through ADO.NET?

  • Thread starter Thread starter DennisWelu
  • Start date Start date
D

DennisWelu

I don't think there is a way. There seems to be a black hole of info
about this unless you are using the older ADO technology.

If you know, please share...!

Dennis
 
There is no lazy write in ado.net.
What exactly are you doing and what's your problem.
 
What exactly are you doing and what's your problem.

That's funny. I get asked that question a lot.

An MDB (Access/Jet) database exists for this project. We are using
ADO.NET to connect to it with the OleDbXXX family of classes. There
are a couple different scenarios where we encounter the problem. One
of the most common is in automated integration tests using a test
version of the database.

Pseudo-code for test fixture setup:

// Create connection object to the MDB and open it
// (Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\...
\Test.mdb;Persist Security Info=False)
// Create command object, CommandType = CommandType.Text
// Set the CommandText to an "INSERT INTO " statement of some sort
// ExecuteNonQuery
// System.Threading.Thread.Sleep(3000);

That Sleep is currently necessary to work around the problem. Without
it the tests will run but fail because they won't see the results of
the INSERT INTO.

I have learned that unlike ADO, in ADO.NET the only way to set
provider specific values is on the connection string. However, based
on http://support.microsoft.com/kb/318161 there no longer seems to be
a way to set the "Jet OLEDB:Flush Transaction Timeout" at all because
it cannot be used in the connection
string, only once a connection has been established.
 
That's funny. I get asked that question a lot.

:-)

It is a weird situation. There should be a way to set that propery even
though ado.net is disconnected (in fact I am not sure why does this matter).
I'll ask around if anybody knows how to set it.
 
Have you tried to use the JRO (Jet Replication Objects) library? I'm also
surprised you can't set this option in the ConnectionString... but then
again, I don't recommend using JET for any serious applications--now that
there are so many other viable alternatives.


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
 
Heya Bill,

William (Bill) Vaughn said:
Have you tried to use the JRO (Jet Replication Objects) library? I'm also
surprised you can't set this option in the ConnectionString...

It is not that surprising since it can't be set within connection string but
later on, after a connection has been estabilished. But yes, I can't see a
valid reason for this behaviour either.

but then
again, I don't recommend using JET for any serious applications--now that
there are so many other viable alternatives.

Totaly agree, but what if there are valid reasons to keep running JET...
 
Yes, I just think it's a waste sending good money after bad. It's kinda like
when someone makes a monumental mistake and spends the rest of their career
trying to put the broken eggs back together.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
 
Yes, I just think it's a waste sending good money after bad. It's kinda like
when someone makes a monumental mistake and spends the rest of their career
trying to put the broken eggs back together.

I'm with you in spirit, Bill. But what if it's a legacy database that
is going to be written out over time? It's often a reality that it's
too costly to rewrite the database and the software components written
on it all at once.

In this particular case we probably could make the decision to switch
over what we have to a direct connect to Express/MDF. But the db is
intended for single-user use and the simplicity of Jet is actually
quite appealing. We will do that if we have to.

Thanks much, Miha and Bill, for sharing your knowledge and toughts.

Dennis
 
So, SQL Express might be overkill for your job--but SQL Server Compact
Edition might be just the ticket. It's lighter than JET and faster. It does
not share the same security issues and is fairly mature in its
implementation. MS is putting significant resources behind it--even building
a new replication engine for it (it already has at least two). See my new
EBook at www.hitchhikerguides.net.


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
 
Back
Top