Opening Access db via DAO in vb.net

Hi

In my vb.net app I am trying to open a db via DAO as below;


Imports dao

Dim dbSynch As dao.Database
dbSynch = DBEngine(0).OpenDatabase("C:\MYDB.MDB")


The problem is that on the last line I am getting the error 'DBEngine' is a
type and cannot be used as an expression. What am I doing wrong?

Many Thanks

Regards

Try:

Dim dbSync As DAO.Database
Set dbSync = OpenDatabase("C:\MYDB.MDB")
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"John" wrote in message
...
Hi

In my vb.net app I am trying to open a db via DAO as below;


Imports dao

Dim dbSynch As dao.Database
dbSynch = DBEngine(0).OpenDatabase("C:\MYDB.MDB")


The problem is that on the last line I am getting the error 'DBEngine' is
a type and cannot be used as an expression. What am I doing wrong?

Many Thanks

Regards

Arvin,

I have tried this one, however I never have used DAO (I used ADO) and could
not get it to work.

I miss this one,
Dim OpenDataBase As New dao.DBEngine

But did not work either.

But the reason that I address this to you, is because of the fact that the
Set will direct be removed from VB2008 when it is typed.

Cor

"Arvin Meyer [MVP]" schreef in bericht
...
Try:

Dim dbSync As DAO.Database
Set dbSync = OpenDatabase("C:\MYDB.MDB")
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"John" wrote in message
...
Hi

In my vb.net app I am trying to open a db via DAO as below;


Imports dao

Dim dbSynch As dao.Database
dbSynch = DBEngine(0).OpenDatabase("C:\MYDB.MDB")


The problem is that on the last line I am getting the error 'DBEngine' is
a type and cannot be used as an expression. What am I doing wrong?

Many Thanks

Regards

What am I doing wrong?

Well :-)

1 Still using Access ( i hope you have a good reasson )
2 Is using DAO while it is already a long , long time ago declared obsolete
even in the end of VB6 it was already declared as obsolete technollogy and
ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you should
not ! but use one of the SQL engines closest to Access is the SQL CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however i
will sure not recomend it to you

set a reference to DAO Project=Add
Reference=COM=Microsoft DAO 3.6 Object Library = dao360.dll or the 350
engine for ACCESS version 2000

Imports System.Runtime.InteropServices


Dim Dbe As DAO.DBEngine
Dim Db As DAO.Database
Dim Rs As DAO.Recordset

Dbe = New DAO.DBEngine()
Db = DbE.OpenDatabase("full path to access mdb")
Rs = Db.OpenRecordset("sql query or table name ")


Above should work but i strongly recomend you to move to one of the sql
family products as nowadays there is absolutely no valid reasson to stick
with Access
for newly developed products .



hth

Michel








"John" schreef in bericht
...
Hi

In my vb.net app I am trying to open a db via DAO as below;


Imports dao

Dim dbSynch As dao.Database
dbSynch = DBEngine(0).OpenDatabase("C:\MYDB.MDB")


The problem is that on the last line I am getting the error 'DBEngine' is
a type and cannot be used as an expression. What am I doing wrong?

Many Thanks

Regards

"Michel Posseth [MCP]" wrote in message
...
What am I doing wrong?
snip
2 Is using DAO while it is already a long , long time ago declared
obsolete even in the end of VB6 it was already declared as obsolete
technollogy and ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you
should not ! but use one of the SQL engines closest to Access is the SQL
CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however i
will sure not recomend it to you
snip

DAO is still the recommended method for accessing data in Microsoft Access
databases if you are using the Jet database engine. Its performance is
significantly better than ADO in this scenario.

Ed Metcalfe.

snip
DAO is still the recommended method for accessing data in Microsoft Access
databases if you are using the Jet database engine.
/snip

Recomended by who ? as MS did not even bother to develop a 64 bit Jet oledb
driver for Access this means that even ADO.Net can`t work with Access
so in my opinion MS doesn`t want you to use Access at all in newly to
develop products . that is probably also the reasson why in all study
materials , examples etc etc only connections to one of the SQL family`s is
shown ( wich by the way do have 64 bit equivalants )


snip
Its performance is
significantly better than ADO in this scenario.

/snip

DAO `s perfomance is superb on ACCESS , as it is a specialized engine
optimized for this database

However my question is should you use a long time ago fased out technology
in a newly developed product ?
as i said when i was programming in VB6 ADO was already declared Obsolete
technology , so using it now in VB.Net is in my opinion foolish

And if we are talking about perfomance lets put the cards right and compares
against SQL server CE wich is the substitute for a Access database in
..Net


Michel



"Ed Metcalfe" schreef in bericht
...

"Michel Posseth [MCP]" wrote in message
...
What am I doing wrong?
snip
2 Is using DAO while it is already a long , long time ago declared
obsolete even in the end of VB6 it was already declared as obsolete
technollogy and ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you
should not ! but use one of the SQL engines closest to Access is the SQL
CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however i
will sure not recomend it to you
snip

DAO is still the recommended method for accessing data in Microsoft Access
databases if you are using the Jet database engine. Its performance is
significantly better than ADO in this scenario.

Ed Metcalfe.

http://msdn2.microsoft.com/en-us/library/ms810810.aspx
scroll to the bottom to see that DAO is officially declared Obsolete ( a
long time ago )
note: that this paper was released the first time in January 2002 but it
was known to the programming comunity long time before that

I am a person with a strong readers memory ( everything i once read stays in
my mind ) so i just looked in my library i knew it was somewhere there
Chapter 8 Databases page 393 and page 394 of the official Core reference
guide of VB6 "Programming Microsoft Visual Basic 6.0".

If you read these 2 pages you will see that DAO is already in the
replacement phase in favor of ADO , the core VB6 book tells you between the
lines that DAO is VB 5.0 and in VB6 projects you should favor the new ADO
engine for the simple reasson that DAO is going to be replaced by ADO
remember that this book is written in early 1999 !!!

A funny thing i just encountered is that the writer of the book ( Balena )
tells you if you really need to use DAO or RDO buy the superb book
"Hitchiker`s guide to Visual basic and SQL server by William R. Vaughn "

Well "William R. Vaughn" is also known as "Bill Vaughn" active in these
newsgroups and he is the person who convinced me that there is absolutely no
reasson at all to stick using Access now we have SQL server CE

If a person walked into my office and dare to propose a desktop app written
in VS.Net 2008 with a ACCESS db backend wich uses DAO i would laugh an not
take this person serious annymore , i doubt if this person is qualified to
do his job right



Michel



"Michel Posseth [MCP]" schreef in bericht
...
snip
DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine.
/snip

Recomended by who ? as MS did not even bother to develop a 64 bit Jet
oledb driver for Access this means that even ADO.Net can`t work with
Access
so in my opinion MS doesn`t want you to use Access at all in newly to
develop products . that is probably also the reasson why in all study
materials , examples etc etc only connections to one of the SQL family`s
is shown ( wich by the way do have 64 bit equivalants )


snip
Its performance is
significantly better than ADO in this scenario.

/snip

DAO `s perfomance is superb on ACCESS , as it is a specialized engine
optimized for this database

However my question is should you use a long time ago fased out technology
in a newly developed product ?
as i said when i was programming in VB6 ADO was already declared Obsolete
technology , so using it now in VB.Net is in my opinion foolish

And if we are talking about perfomance lets put the cards right and
compares against SQL server CE wich is the substitute for a Access
database in .Net


Michel



"Ed Metcalfe" schreef in bericht
...

"Michel Posseth [MCP]" wrote in message
...
What am I doing wrong?
snip
2 Is using DAO while it is already a long , long time ago declared
obsolete even in the end of VB6 it was already declared as obsolete
technollogy and ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you
should not ! but use one of the SQL engines closest to Access is the SQL
CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however
i will sure not recomend it to you
snip

DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine. Its
performance is significantly better than ADO in this scenario.

Ed Metcalfe.

"Michel Posseth [MCP]" wrote in message
...

http://msdn2.microsoft.com/en-us/library/ms810810.aspx
scroll to the bottom to see that DAO is officially declared Obsolete
( a long time ago )
note: that this paper was released the first time in January 2002 but
it was known to the programming comunity long time before that

At our last MVP Summit in Seattle, we were specifically told by Microsoft
that DAO is the preferred method of dealing with JET and SQL-Server
databases from Access front-ends, reversing decisions made ssome time ago.

ADO is obsolete, having been replaced by ADO.NET.

The design structure of Access for dealing with databases is so complete and
therefore complex, that I believe that there haven't been any .NET efforts
made to work with it yet. It may be several years before Microsoft builds
any .NET capability into Access. Until then, DAO is the faster and more
complete method of dealing with JET data.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

An interesting discussion. Since my name was brought up, I thought I should
weigh in.

As as consultant/mentor I spend an inordinate amount of time undoing
the exuberance of Access/JET developers and the applications the databases
that seem to spread like a virus through one department in an organization
after another. Case in point: a local hospital has thousands of JET
databases that contain patient data. They aren't HIPA-or
Sarbanes-Oxley-compliant and can't be so they must be converted and secured.
These and many other IT organizations have spent an unbelievable amount of
money and time to undo this mess.
Security is not the only issue. We still hear reports of applications
that outgrow their design because of success, lack of foresight or skill. We
hear that a popular application in one department spreads to others as
everyone wants to share the data. But the fundamental CP/M-class DBase
shared-file architecture is not designed for scalability. Sure, you can
store a "lot" of data, but each and every application that's accessing the
shared file is doing physical IO over the LAN. More data means more network
traffic and more vulnerability--lose a packet and the data is ???,
disconnect a client and the data is ???. While having uncommitted cached
rows can threaten data integrity, JET does not write to the database when
you tell it to--it caches writes to improve performance and unless you give
up performance and scalability for immediate data IO operations.
Unlike SQL Server, JET is not logged--when the power fails is committed
data written to the database and uncommitted transactions backed out? Ah,
no. IMHO JET is designed for small, light, 1 to few user database
applications where security is not important, where client data is
unimportant, where scalability is not important. Yes, there are lots of
places where you'll find applications like this--like the choir roster.
Sure, there are a lot of JET/DAO/Access applications out there and lots of
developers who are proficient at keeping them running--just like there are a
lot of '57 Chevy experts in Cuba as that's all they have to work with and
that's what they know best. When all you have is apples, you don't make a
lot of turkey sandwiches.

The other issue is application conversion scalability. So, your JET
application is successful. Your customer wants to share the data all over
the world or perhaps just all over the 14th floor--all 65 or 650 clients.
Now what? JET/Access/DAO/ADO.NET code is tough to port as it probably uses
the features that make JET fast and scalable but make it harder to convert
to a Web-based or client-server architecture. What do you do? Start over?
Get new developers? IMHO it makes more sense to think about scalability,
security and stability long before the first line of code is written. That's
tough when the foundation is adobe bricks.

It's for these and other reasons I can't in good conscious recommend it
to any business customers.

Microsoft has many divisions with many agendas. Access is a powerful
tool with a large, loyal (and often skilled) following of developers. I can
see how MS would want to continue to support Access and JET and it
is--Access 2007 still supports it. MS does not support DAO--we've all heard
that any number of times. That said, I agree DAO is the fastest way (closest
to the "native" way) to access JET--ADO and ADO.NET shove many layers in the
way. Layers :: slow and loss of features. And yes, JET/DAO make a sad
interface to SQL Server.
Yes, MS has improved and tuned the OLE DB providers for COM and .NET.
However, Microsoft has also spent considerably more time and money tuning
and configuring SQL Server to replace JET. SQL Express is one edition. Yes,
I'll be the first to agree that it's overkill for many applications where
JET is the current DBMS engine. However, SQL Server Compact Edition is not.
This is not a new player but an experienced engine that's ideal for the
single-user to the disconnected shared-database-via-synchronization
architectures of the 21st century. Like SQL Server 2008, SQLCe can encrypt
the entire database. This means when it's on that laptop containing the
Veterans Administration data and ends up in the hands of a creep, the data
is still safe. SQLCe has it's own native managed .NET provider. JET still
needs an OLE DB provider. That alone should imply MS's long-term intent.

I think MS would be well served to have Access add (or replace) JET with
SQL Server Express and Compact Edition... but that's just me. Yes, it's
going to be hard to take. I've been in this business for over 35 years.
We've all seen old technologies hold on long after their replacements have
come. Those that ride the wave of change seem to go on to the next wave.
Those that get behind sometimes drown.

--
__________________________________________________ ________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
__________________________________________________ __________________________________________
"Michel Posseth [MCP]" wrote in message
...

http://msdn2.microsoft.com/en-us/library/ms810810.aspx
scroll to the bottom to see that DAO is officially declared Obsolete
( a long time ago )
note: that this paper was released the first time in January 2002 but
it was known to the programming comunity long time before that

I am a person with a strong readers memory ( everything i once read stays
in my mind ) so i just looked in my library i knew it was somewhere there
Chapter 8 Databases page 393 and page 394 of the official Core reference
guide of VB6 "Programming Microsoft Visual Basic 6.0".

If you read these 2 pages you will see that DAO is already in the
replacement phase in favor of ADO , the core VB6 book tells you between
the lines that DAO is VB 5.0 and in VB6 projects you should favor the new
ADO engine for the simple reasson that DAO is going to be replaced by ADO
remember that this book is written in early 1999 !!!

A funny thing i just encountered is that the writer of the book ( Balena )
tells you if you really need to use DAO or RDO buy the superb book
"Hitchiker`s guide to Visual basic and SQL server by William R. Vaughn "

Well "William R. Vaughn" is also known as "Bill Vaughn" active in these
newsgroups and he is the person who convinced me that there is absolutely
no reasson at all to stick using Access now we have SQL server CE

If a person walked into my office and dare to propose a desktop app
written in VS.Net 2008 with a ACCESS db backend wich uses DAO i would
laugh an not take this person serious annymore , i doubt if this person is
qualified to do his job right



Michel



"Michel Posseth [MCP]" schreef in bericht
...
snip
DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine.
/snip

Recomended by who ? as MS did not even bother to develop a 64 bit Jet
oledb driver for Access this means that even ADO.Net can`t work with
Access
so in my opinion MS doesn`t want you to use Access at all in newly to
develop products . that is probably also the reasson why in all study
materials , examples etc etc only connections to one of the SQL family`s
is shown ( wich by the way do have 64 bit equivalants )


snip
Its performance is
significantly better than ADO in this scenario.

/snip

DAO `s perfomance is superb on ACCESS , as it is a specialized engine
optimized for this database

However my question is should you use a long time ago fased out
technology in a newly developed product ?
as i said when i was programming in VB6 ADO was already declared Obsolete
technology , so using it now in VB.Net is in my opinion foolish

And if we are talking about perfomance lets put the cards right and
compares against SQL server CE wich is the substitute for a Access
database in .Net


Michel



"Ed Metcalfe" schreef in bericht
...

"Michel Posseth [MCP]" wrote in message
...
What am I doing wrong?
snip
2 Is using DAO while it is already a long , long time ago declared
obsolete even in the end of VB6 it was already declared as obsolete
technollogy and ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you
should not ! but use one of the SQL engines closest to Access is the
SQL CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however
i will sure not recomend it to you
snip

DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine. Its
performance is significantly better than ADO in this scenario.

Ed Metcalfe.

Michael,

In my idea you should not put so much effort to tell that the world is
round.

:-)

Cor


"Michel Posseth [MCP]" schreef in bericht
...
snip
DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine.
/snip

Recomended by who ? as MS did not even bother to develop a 64 bit Jet
oledb driver for Access this means that even ADO.Net can`t work with
Access
so in my opinion MS doesn`t want you to use Access at all in newly to
develop products . that is probably also the reasson why in all study
materials , examples etc etc only connections to one of the SQL family`s
is shown ( wich by the way do have 64 bit equivalants )


snip
Its performance is
significantly better than ADO in this scenario.

/snip

DAO `s perfomance is superb on ACCESS , as it is a specialized engine
optimized for this database

However my question is should you use a long time ago fased out technology
in a newly developed product ?
as i said when i was programming in VB6 ADO was already declared Obsolete
technology , so using it now in VB.Net is in my opinion foolish

And if we are talking about perfomance lets put the cards right and
compares against SQL server CE wich is the substitute for a Access
database in .Net


Michel



"Ed Metcalfe" schreef in bericht
...

"Michel Posseth [MCP]" wrote in message
...
What am I doing wrong?
snip
2 Is using DAO while it is already a long , long time ago declared
obsolete even in the end of VB6 it was already declared as obsolete
technollogy and ADO was prefered

If you nowadays still use ACCESS in my opinion for new projects you
should not ! but use one of the SQL engines closest to Access is the SQL
CE engine
, e.g. sql server everywhere then you should connect with ADO.Net.

So having said this it is still possible to connect with DAO , however
i will sure not recomend it to you
snip

DAO is still the recommended method for accessing data in Microsoft
Access databases if you are using the Jet database engine. Its
performance is significantly better than ADO in this scenario.

Ed Metcalfe.