DAO 2.5 to DAO 3.5 and Access 2.0 to Access 97 Answers and Questions (VB5)

DAO 2.5 to DAO 3.5 and Access 2.0 to Access 97 Answers and Questions (VB5)

Post by George Raudabaug » Fri, 21 Mar 1997 04:00:00



I've inherited a rather huge amount of VB3.0 code over the last 6 months.
During that time I've moved the database engine from the great XBS200 Dbase
DLL that Jet provided to the mighty MSAJT200 Access DLL that also came with
VB3.0.  For a multiuser application, using Truegrid, using Crystal, (and
I'm really not pulling my hair out because I have MPB).

Fortunately, my employer has given me all the toys I've requested to move
this thing up a few generations (and a ticket to put this thing to sleep
permanently via a rewrite, but thats a much larger task).

Being brave I've tried to do this with VB5.  What I found:

1.  The default DAO module with an upgrade is the 2.5/3.0 compatibility
version.  Against an Access 2.0 database its actually slower.  Converting
the DB to Access 95 format improved performance, but not significantly.
Using this did not require a significant amount of code changes.  The main
one was is an empty string the same as null - this flipflopped yet again.
2.  The new 3.5 DAO module required a significant amount of work since the
code I got uses the Table object all over the place. I saw some performance
improvements (now about 20% of the original).

My Questions:

1.  It was not clear if moving to the new 3.5 DAO module without converting
to Access 97 format would make any difference (really, it was not clear if
there was any difference between the Access 97 and 95 formats).  Any news
on this?
2.  It was not clear if I would gain any locking (page vs. record-level)
advantages using DAO 3.5.  The help implied that a RecordSet object of Type
table still used page level locking.
3.  Unrelated, does anybody know of a report package that can print stuff
in fixed positions (within 1/16 inch) even if the printer type is changed -
this is for preprinted forms.  Also, does anyone know of a good substitute
for DBGrid that allows movable columns - this is an absolute requirement
with our product set.

Thanks,

George Raudabaugh

 
 
 

DAO 2.5 to DAO 3.5 and Access 2.0 to Access 97 Answers and Questions (VB5)

Post by Jim Fergus » Sat, 22 Mar 1997 04:00:00


George,

Quote:>1.  It was not clear if moving to the new 3.5 DAO module without converting
>to Access 97 format would make any difference (really, it was not clear if
>there was any difference between the Access 97 and 95 formats).  Any news
>on this?

If you don't convert the physical MDB file to the Jet 3.0 format then
Jet 3.x has to treat it as an IISAM data source like dbase or foxpro.
For best performance you should convert to Jet 3.0 format. The only
side-effect of doing this that I know of are that if you have very
many Access objects such as forms and module code, the database will
increase in size substantially.

Quote:>2.  It was not clear if I would gain any locking (page vs. record-level)
>advantages using DAO 3.5.  The help implied that a RecordSet object of Type
>table still used page level locking.

Jet still locks at the page level of granularity. This hasn't changed.
Jet has changed for better concurrency when you have many simultaneous
INSERTS, because the 'new' page is not locked unlike Jet 2.0.

There's quite a bit of detailed info on this stuff (AKA "White
Papers") on MS's web site at http://www.microsoft.com/accessdev

-- Jim Ferguson, FMS
   http://www.fmsinc.com

 
 
 

DAO 2.5 to DAO 3.5 and Access 2.0 to Access 97 Answers and Questions (VB5)

Post by Joe Mak » Sat, 22 Mar 1997 04:00:00


Quote:>really, it was not clear if
>there was any difference between the Access 97 and 95 formats

No difference.

    ...Joe Maki
    MT Kupp & Associates

 
 
 

DAO 2.5 to DAO 3.5 and Access 2.0 to Access 97 Answers and Questions (VB5)

Post by Richard Borri » Sun, 23 Mar 1997 04:00:00


In VB5 there is a new MS control called Flexgrid.  It might help.

Richard

Quote:>.  Also, does anyone know of a good substitute
> for DBGrid that allows movable columns - this is an absolute requirement
> with our product set.

 
 
 

1. Converting VB3(DAO 2.5) - VB6(DAO 3.5) Strategy Needed

MINOR PROBLEM:

Before I explain my major problem, I better explain my minor problem.
My minor problem is terminology. From 1994 - 1998 I have created
programs whose data could be viewed, repaired and compacted with
Access 2. I think that would be DAO 2.5. I know at one time there were
more references to "Jet" than "DAO". The version of msajt200.dll that
we shipped with those applications was 2.50.xxx. I suppose the VB6
equivalent of VB3's DAO 2.5 would be DAO 3.5. I noticed msjet35.dll
(version 3.51.2026.0) is in my \WINDOWS\SYSTEM directory. Does that
mean Jet 2.5 = DAO 2.5 and Jet 3.5 = DAO 3.5? What I am getting at is
that I might not be using the proper terminology in stating my "major"
problem.

MAJOR PROBLEM:

I am in the process of converting my VB3 (DAO 2.5) applications to VB6
(DAO 3.5). I am currenly working on the applications that do not
access databases. That will change shortly.

I have one "master" application that adds, edits records to a
database. That master application also is the only application with
the capability to compact and repair.

I have another application (REPORTS) that creates a report using the
database created from the master application.

I have another application (ZIPCODES) that takes that data created in
the master application, and revises zipcodes for the database. I have
other applications that use the database, but, for the purpose of
discussion, this will do.

I would rather make as few code changes as possible at a given time.

Is it possible (and is it a good idea) to convert the applications
from VB3 to VB6 while staying with DAO 2.5? That way I could isolate
my problems that have to do with the non database issues of converting
to VB6.

Can I convert my REPORTS or ZIPCODE to VB6 (DAO 3.5) while the master
application is still VB3 (DAO 2.5)? Once REPORTS and ZIPCODE
applications are running OK with DAO 3.5, I would convert the master
app to DAO 3.5.

What I don't want to do is convert all three applications at the once.
That would make it harder for me to isolate my mistakes.

Thank you in advance for spending the time to read this! Any
suggestions would be appreciated.

Dave Kaufmann - Denver Tax Software

2. Hop their is a way

3. MS Access 97/DAO 3.5 transaction support

4. TopLink expertise needed !!!

5. Delphi 3.0, Access 97, DAO 3.0/3.5

6. ALTER TABLE

7. DAO 2.5 / Access 2.0 / VB 4.0 / NT Server Access MDB corruption problem

8. Oracle on Red Hat linux 6.2

9. VB4 and DAO 3.5 (Access 97)

10. Access 97 files without DAO 3.5

11. Error handling VB5/DAO 2.5/3.5 and Sql Server 7.0

12. VB5 DAO 3.5 FoxPro 2.5 Tables

13. RICS version of VB5 and DAO 2.5/3.5 compatibility