MS Access 97 vs. XP/2003

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have been tasked to begin developing dbs in XP and 2003. I have one user
who refuses to learn ADO and wants to develop only for 97 DAO. Besides the
obvious issues, will I have to always include a DAO reference to make sure
the XP 2003 dbs will work if I have to convert a db for the 97 format? Is it
even an issue?
Thanks!
 
Actually, there's no reason NOT to continue using DAO. DAO was designed
specifically for Jet databases (i.e. MDB files), so it's almost always
faster than using ADO against a Jet database (more levels of abstraction to
go through). Add to that the fact that ADO is officially defunct (replaced
by ADO.Net).

In any case, Access 2003 already includes a DAO reference: Microsoft saw the
error of their ways from Access 2000 and 2002 <g>. However, it's lower in
the sequence of references than ADO, so you'll find that you'll need to
"disambiguate" certain declarations, since objects with the same names exist
in the 2 models. For example, to ensure that you get a DAO recordset, you'll
need to use Dim rsCurr as DAO.Recordset (to guarantee an ADO recordset,
you'd use Dim rsCurr As ADODB.Recordset)

The list of objects with the same names in the 2 models is Connection,
Error, Errors, Field, Fields, Parameter, Parameters, Property, Properties
and Recordset.
 
Doug:
What do you mean ADO is replaced by ADO.Net? They aren't the same? Would
that affect Access vba code since Access is not .Net?

Sam

Douglas J. Steele said:
Actually, there's no reason NOT to continue using DAO. DAO was designed
specifically for Jet databases (i.e. MDB files), so it's almost always
faster than using ADO against a Jet database (more levels of abstraction to
go through). Add to that the fact that ADO is officially defunct (replaced
by ADO.Net).

In any case, Access 2003 already includes a DAO reference: Microsoft saw the
error of their ways from Access 2000 and 2002 <g>. However, it's lower in
the sequence of references than ADO, so you'll find that you'll need to
"disambiguate" certain declarations, since objects with the same names exist
in the 2 models. For example, to ensure that you get a DAO recordset, you'll
need to use Dim rsCurr as DAO.Recordset (to guarantee an ADO recordset,
you'd use Dim rsCurr As ADODB.Recordset)

The list of objects with the same names in the 2 models is Connection,
Error, Errors, Field, Fields, Parameter, Parameters, Property, Properties
and Recordset.
Click to expand...
 
Doug:
What do you mean ADO is replaced by ADO.Net? They aren't the same? Would
that affect Access vba code since Access is not .Net?
Click to expand...

They are similar in the first three letters of their name, and in
almost no other respect. :-{( It leaves us Access programmers dealing
with either "obsolete" (but still very powerful, effective, supported,
and useful) DAO, or with (more flexible, deprecated, but usable) ADOX.


John W. Vinson[MVP]
 
I really need to understand this. I am prototyping in MS Access with unbound
forms with the intention of taking that to .net, probably vb.net (this will
be a web-based app). All the connections to the SQL DB are via ADO. My
expectation was that translation would be a snap. Am I wrong?

Sam
 
smk23 said:
I really need to understand this. I am prototyping in MS Access with
unbound forms with the intention of taking that to .net, probably
vb.net (this will be a web-based app). All the connections to the SQL
DB are via ADO. My expectation was that translation would be a snap.
Am I wrong?
Click to expand...

Probably.

Also be aware that an Access form is VERY different from the forms in .Net so
any of the codeing you have there will likely not port over without considerable
rework as well.
 
I have run across the DAO/ADO issue you discussed. I am learning VB .NET so I
can design applications that pull data from Access and 3rd party dbs since my
company uses SQL Server and Oracle (different departments that my department
pulls data from) Right now some fear Access 2003 has too many 'bugs' and they
want to hold on to 97 for dear life. These people don't even write major VBA
code. I think it is they don't want to learn the new intercase as 97 is
different from 2000,XP and 2003.

I am glad I started this dialog. I like ADO and I like the way I can
incorporate pivot tables into forms and display data without having to call
Excel. The solution I posed is middle of the road and hopefully the users
will understand. I suggested we install 2003 on all computers in a seperate
directory from 97. That way they can run reports or continue to store data in
their familiar routine but when they need to use the power applications I
develop, they can call up 2003.

We use a FOCUS Mainframe to collect client data from the field and Extra! is
used to pull data in FOCUS queries. Can Access tap into FOCUS? I know MS
products use ANSI SQL and as long as 3rd party dbs are ODBC compliant, a
connection can be made. Has anyone had experience pulling data from a
Mainframe system?


Douglas J. Steele said:
Actually, there's no reason NOT to continue using DAO. DAO was designed
specifically for Jet databases (i.e. MDB files), so it's almost always
faster than using ADO against a Jet database (more levels of abstraction to
go through). Add to that the fact that ADO is officially defunct (replaced
by ADO.Net).

In any case, Access 2003 already includes a DAO reference: Microsoft saw the
error of their ways from Access 2000 and 2002 <g>. However, it's lower in
the sequence of references than ADO, so you'll find that you'll need to
"disambiguate" certain declarations, since objects with the same names exist
in the 2 models. For example, to ensure that you get a DAO recordset, you'll
need to use Dim rsCurr as DAO.Recordset (to guarantee an ADO recordset,
you'd use Dim rsCurr As ADODB.Recordset)

The list of objects with the same names in the 2 models is Connection,
Error, Errors, Field, Fields, Parameter, Parameters, Property, Properties
and Recordset.
Click to expand...
 
smk23 said:
I really need to understand this. I am prototyping in MS Access with unbound
forms with the intention of taking that to .net, probably vb.net (this will
be a web-based app). All the connections to the SQL DB are via ADO. My
expectation was that translation would be a snap. Am I wrong?

Sam
Click to expand...

Yes, I'm afraid you are very wrong. As others have pointed out, ADO.Net is
a completely different product to ADO, you cannot simply convert code using
ADO to ADO.Net. Furthermore, VB.Net is a very different product to all
preceding versions of VB e.g. VB6, VBA. You cannot simply run your VBA code
in VB.Net, it is a different language. There are enough similarities to
make conversion feasible, but it will not be a trivial exercise.

However, if you are ultimately targetting a web-based application, then your
entire architecture is going to be all wrong if you design it in Access. In
..Net, web forms and ADO.Net work on the basis that that the client data is
"disconnected" from the database: data gets queried from the database by the
web server, shipped out in a web page in the form of a disconnected
recordset, and then the web server forgets about it. The disconnected
recordset, containing modified data, may or may not come back eventually.
If it does, it then gets processed completely independently of the original
recordset created from the original query, which is by now long forgotten.

This is very different from the way that the "connected" recordsets that you
get in DAO and ADO work, which are closely tied into the database at all
times.

Also, you will find that what you can do in web forms in terms of the user
interface is very different to what you can do in Access, which means that
Access is a very questionable tool for prototyping web forms.
 
Back
Top