Should the backend be changed to Access 2003 ?

[Peter]

Hi,

We are going to change the front end of Access 97 application to Access
2003.

Is there any need to change backend to Access 2003 or should we keep it
unchanged ?

Thanks
Peter

 

[Douglas J. Steele]

If you're not going to be taking advantage of the Unicode availability in
Access 2003 (it was introduced in Access 2000), there really isn't any
driving reason to convert. You will be able to store more data in the newer
format (the size limit increases to 2 Gb from 1 Gb), but since Unicode takes
2 bytes instead of 1 byte, that doesn't actually equal a doubling in
capacity.

 

[Jamie Collins]

If you're not going to be taking advantage of the Unicode availability in
Access 2003 (it was introduced in Access 2000), there really isn't any
driving reason to convert.

What about the DECIMAL data type, table-level CHECK constraints,
CASCADE referential actions, improved SQL DDL, ...?

You will be able to store more data in the newer
format (the size limit increases to 2 Gb from 1 Gb), but since Unicode takes
2 bytes instead of 1 byte, that doesn't actually equal a doubling in
capacity.

See:

Description of the new features that are included in Microsoft Jet 4.0

http://support.microsoft.com/kb/275561

Compressible data types

"This attribute was added for Character fields because of the change
to the Unicode character representation format. Unicode characters
uniformly require two bytes for each character. For existing Microsoft
Jet databases that predominantly contain character data, this could
mean that the database file would nearly double in size when converted
to the Microsoft Jet 4.0 format. Yet the Unicode representation of
many character sets (those formerly denoted as Single-Byte Character
Sets, SBCS) can easily be compressed to a single byte."

Jamie.

--

 

[David W. Fenton]

If you're not going to be taking advantage of the Unicode
availability in Access 2003 (it was introduced in Access 2000),
there really isn't any driving reason to convert. You will be able
to store more data in the newer format (the size limit increases
to 2 Gb from 1 Gb), but since Unicode takes 2 bytes instead of 1
byte, that doesn't actually equal a doubling in capacity.

If you're not going to run a mixed front end environment (i.e., A97
and A2K3), then I see no reason *not* to convert the back end to A2K
(not A2K3 -- A2K3 is irrelevant for a back end, because you're not
using Access features of the MDB, only Jet). I believe that using
the same Jet version does improve performance.

I had an app that was converted from Access 2 to A2K that I was
developing for in A97 and I kept the back end in A97 after we
encountered some corruption issues using A2K format (this was the
bad old days of 2000-01, before Jet 4 SP 6). The A97 (i.e., Jet 3.5)
back end was very, very stable and uncorruptable. Eventually, we
moved to an A2K back end to eek out the last little bits of
performance and as long as we kept all the workstations properly
"service packed" for Jet and Access, it worked like a treat. And
there really was a performance gain, particularly in retrieving
relatively large recordsets.