Microsoft Works

[cisotta]

Does anyone know how to access directly Microsoft Works database files (*.wdb)?

I don't think DAO will help, and would like to avoid using a ODBC server...

thanks
francesco

 

[RileyCat]

Try ADO instead -- it should work!

 

[Cagliostro]

ADO will call ODBC in this case. Is there a serious reason to not use ODBC?

Ion Filipski

 

[cisotta]

Actually I would like to access the wdb file directly (as with DAO), without setting up a Windows engine that controls the database and make data available through ODBC connection (this is what I have understood about ODBC).
Isn't ADO like this?

 

[Cagliostro]

the ODBC function SQLDriverConnect access a databse without it to have a DSN registered in the ODBC. When using ADO method open you will give the same connection string as in ODBC for function SQLDriverConnect. So, you will do the same thing if you use ODBC or if you use ADO.

Ion Filipski

 

[cisotta]

I'm not so expert about these data access tecniques, just tried DAO (Data Access Object) that allowed me to open a MS-Access database directly from application without setting up a driver interface inside Windows.

Now I'm going to build an application that should read a MS-Works wdb database, but would appreciate that my program could access the database file directly, without me having to go to the user's home personally and set up ODBC stuff on his PC.

 

[Cagliostro]

Let's say again, if you use ODBC to access database that does not mean at all what you have to configure something in ODBC in order to access the database. There are two ODBC functions you may use
1. SQLConnect
this function require DSN in ODBC
2. SQLSriverConnect
this function does not require DSN in ODBC
both of them are ODBC functions. In the case you use DAO to access some non JET accessible databases you will invoke ODBC. The same thing you will do if you use ADO.

Ion Filipski

 

[cisotta]

I think the problem is that support to Works database format has been discontinued in either ODBC drivers and even in Ms-Office standard file operations.

It seems that all existing Works databases have now to be converted to Access format.

 

[ArkM]

Some addition: MS said (in MSDN) that DAO is obsolete and not supported now (and ODBC is obsolete too. They insist on using ADO in all new codes...

 

[Cagliostro]

could you please give the link to that obsoletes?

Ion Filipski

 

[ArkM]

See MSDN on-line, data access topics. It's a hard job to find any DAO references in MSDN now...
Some quotas:
From MSDN (July 2002):
Microsoft® Access 2000 supports two data access models: the traditional Data Access Objects (DAO) and ActiveX® Data Objects (ADO). DAO targets the Microsoft Jet database engine to enable quick and easy database programming. Access 2000 is the first version of Access to also support ADO for manipulating Jet databases. Instead of being based on a single database engine, ADO uses a common programming model to deliver access to universal data. It relies on OLE DB providers for low-level links to data sources. OLE DB technologies will eventually make their ODBC predecessors obsolete, much as ADO will replace DAO. Therefore, if you invest in learning ADO now, you will get on the fast track to adopting future improvements in data access with upcoming versions of Access and you'll be able to use more and different kinds of data sources

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdconprerequisites.asp:

ODBC Provider (MSDASQL)
You are strongly encouraged to use one of the native OLE DB Providers instead of the Microsoft Open Database Connectivity (ODBC) Provider. Native OLE DB Providers provide better application stability and performance. Furthermore, native OLE DB Providers will be supported in the future, whereas MSDASQL will not have any new features added to it, will not be available on 64-bit, and will not be accessible from the OLE DB NET Data Provider.

DAO is Jet interface. The Jet has no future. Well, ODBC don't disappear tomorrow but this (MS) standard is obviousky doomed (by MS. In Windows world data access mainstream is OLE DB with ADO interface...

As far as I know, current MDAC packages don't include DAO modules...