By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,369 Members | 1,599 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,369 IT Pros & Developers. It's quick & easy.

ADODB

P: n/a
Hi,

In VB6 when using ADO e.t.c, it was often required to called the function
db.engine.idle, otherwise MS Access took ages to release record locks and
basically made concurrent use impossible.

Will I suffer the same problems with ADODB in VB.NET? if so is there a
correct method to also implement this function. or does good old ADODB do
all this for me?

Thought I'd enquire as I've found no reference to this and didn't want to be
caught out in the later stages of my project..

Thanks,

Merlin
Nov 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Merlin" <je**@jg-tech.co.uk> wrote in message
news:be**********@sparta.btinternet.com...
Hi,

In VB6 when using ADO e.t.c, it was often required to called the function
db.engine.idle, otherwise MS Access took ages to release record locks and
basically made concurrent use impossible.

Will I suffer the same problems with ADODB in VB.NET? if so is there a
correct method to also implement this function. or does good old ADODB do
all this for me?


As far as I know, ADODB is just a namespace for the ADO COM library. But
symantics aside, I think the ADO.NET people could better awnser this
question:

microsoft.public.dotnet.framework.adonet

HTH,
Jeremy

Nov 19 '05 #2

P: n/a
On Wed, 9 Jul 2003 12:39:09 +0000 (UTC), "Merlin" <je**@jg-tech.co.uk> wrote:

Hi,

In VB6 when using ADO e.t.c, it was often required to called the function
db.engine.idle, otherwise MS Access took ages to release record locks and
basically made concurrent use impossible.

Will I suffer the same problems with ADODB in VB.NET? if so is there a
correct method to also implement this function. or does good old ADODB do
all this for me?

Thought I'd enquire as I've found no reference to this and didn't want to be
caught out in the later stages of my project..

I'm assuming you're referring to DAO (DBEngine.Idle) and not ADO.

ADO.NET operates a bit differently than DAO (and ADO) in that for the most part your data is in a
disconnected state. Whether you use SQL statements, stored procedures or the data objects, updates
operate under optimistic concurrency - which means that locking only occurs for the duration of
database update. There is no supported client-side edit locking mode. Edit locking (pessimistic
concurrency) only occurs at the database (server-side) level.
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
Nov 19 '05 #3

P: n/a

"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:is********************************@4ax.com...
On Wed, 9 Jul 2003 12:39:09 +0000 (UTC), "Merlin" <je**@jg-tech.co.uk> wrote:
Hi,

In VB6 when using ADO e.t.c, it was often required to called the function db.engine.idle, otherwise MS Access took ages to release record locks and basically made concurrent use impossible.

Will I suffer the same problems with ADODB in VB.NET? if so is there a
correct method to also implement this function. or does good old ADODB do all this for me?

Thought I'd enquire as I've found no reference to this and didn't want to be caught out in the later stages of my project..

I'm assuming you're referring to DAO (DBEngine.Idle) and not ADO.

ADO.NET operates a bit differently than DAO (and ADO) in that for the most part your data is in a disconnected state.


This is, of course, depending on what ADO.NET objects you are using & how
you write your data-access layer.

Nov 19 '05 #4

P: n/a
On Wed, 09 Jul 2003 14:00:50 GMT, "Jeremy Cowles" <je*************************@asifl.com> wrote:


"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:is********************************@4ax.com...
> On Wed, 9 Jul 2003 12:39:09 +0000 (UTC), "Merlin" <je**@jg-tech.co.uk>
wrote:
>
> Hi,
>
> In VB6 when using ADO e.t.c, it was often required to called the
function
> db.engine.idle, otherwise MS Access took ages to release record locks
and
> basically made concurrent use impossible.
>
> Will I suffer the same problems with ADODB in VB.NET? if so is there a
> correct method to also implement this function. or does good old ADODB
do
> all this for me?
>
> Thought I'd enquire as I've found no reference to this and didn't want
to be
> caught out in the later stages of my project..
>
> I'm assuming you're referring to DAO (DBEngine.Idle) and not ADO.
>
> ADO.NET operates a bit differently than DAO (and ADO) in that for the most
part your data is in a
> disconnected state.

This is, of course, depending on what ADO.NET objects you are using & how
you write your data-access layer.

Not sure what you're getting at. Do you have an example?
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)
Nov 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.