update from old technology
dave
I have inherited an old vb6/vc++ app that needs to be updated to run on
vista. currently it appears that the old dao 2.5/3.51 stuff is one of the
sticking points. what is the recommended migration path up from that to
something that will work in vista/win-7, but still be compatible with win2k
and xp for at least the next couple years?
both parts of this use access-97 vintage databases. what would be the best
format to upgrade those to??
on the vb6 side i would hate to have to rewrite lots of code, is there
something that would keep constructs like this still operable, or will these
require rewriting?
DatabasePath = gDBName + ".mdb" 'get the path of the database
Set Db = DBEngine.Workspaces(0).OpenDatabase(DatabasePath)
SQLquery = "SELECT * FROM " + Table + " WHERE " + Field + " = '" + value +
"'" 'set the query
Set Rs = Db.OpenRecordset(SQLquery, dbOpenDynaset) 'open the database
the c++ side uses several recordset classes inherited from CDaoRecordset,
what would be the best way to upgrade those? These access the old access
database.
and last but not least in a newer part of the c++ there are several uses of
CDatabase/CRecordset being used with odbc connect strings for more generic
data access. I 'think' these will still be ok in vista/win-7, is that
correct??
Bob Barrows
> lots of questions...
>
> I have inherited an old vb6/vc++ app that needs to be updated to run
> on vista. currently it appears that the old dao 2.5/3.51 stuff is
> one of the sticking points. what is the recommended migration path
> up from that to something that will work in vista/win-7, but still be
> compatible with win2k and xp for at least the next couple years?
>
DAO <> ADO/OLEDB/ODBC ... but ... why not simply install the needed
libraries on the vista machines?
> both parts of this use access-97 vintage databases. what would be
> the best format to upgrade those to??
Why not leave them as-is?
>
> on the vb6 side i would hate to have to rewrite lots of code, is there
> something that would keep constructs like this still operable, or
> will these require rewriting?
DAO <> ADO so this code would require rewriting if you switched to ADO or
.Net
>
> the c++ side uses several recordset classes inherited from
> CDaoRecordset, what would be the best way to upgrade those? These
> access the old access database.
Why change them? Why not install the needed libraries on the vista machine?
>
> and last but not least in a newer part of the c++ there are several
> uses of CDatabase/CRecordset being used with odbc connect strings for
> more generic data access. I 'think' these will still be ok in
> vista/win-7, is that correct??
Given that the needed libraries are installed, I guess they would be "ok"
...
Bottom line: upgrading will require a rewrite. If you're going to upgrade,
you may as well go straight to .Net.
--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Ralph
"dave" <da...@discussions.microsoft.com> wrote in message
news:B62B63B7-8169-4C52...@microsoft.com...
>
>
> "Bob Barrows" wrote:
>
> > dave wrote:
> > > lots of questions...
> > >
> > > I have inherited an old vb6/vc++ app that needs to be updated to run
> > > on vista. currently it appears that the old dao 2.5/3.51 stuff is
> > > one of the sticking points. what is the recommended migration path
> > > up from that to something that will work in vista/win-7, but still be
> > > compatible with win2k and xp for at least the next couple years?
> > >
> >
> > DAO <> ADO/OLEDB/ODBC ... but ... why not simply install the needed
> > libraries on the vista machines?
>
> doesn't work. My not always so good memory of some article about vista
was
> that some of the old database access components were being deprecated
because
> they could not be cleaned up enough to get rid of security problems. I
> 'thought' that included some of the old access97 and dao or jet components
> that this old app used... but that was over a year ago when this topic
first
> came up.
>
You can not install the MDAC or its components on Vista. Don't even try.
With Vista MDAC has been superceded by "DAC 6" (Data Access Components)
which comes with the O/S. DAO should already be installed as well. Primarily
by a "Jet 4" Hotfix installed with SPs, so if you have an early edition of
Vista (or XP) make sure you have upgraded to the latest service patch.
Some background:
The original MDAC ("Microsoft Data Access Components") include not only
support for ADO and DAO data access libraries, but also OLE DB providers and
ODBC drivers, and OLE 'system' components. Even though the MDAC components
contained all these items they were 'versioned' by the highest level of ADO
they supported.
The MDAC suite was designed to provide universal data access for all
applications. It was release independently of O/S service packs and products
since improvements in ADO, DAO, OLE DB, Jet, SQL Server, etc, where on a
different development track from that of Windows or Office itself.
Eventually DAO and Jet 4 (mdb) support was removed from the MDAC package,
and placed in their own Jet packages.
Also, primarily because of the OLE components, the MDAC also became
platform-specific - thus MDAC 2.8 for Windows 2000, one for XP, etc.
With Vista, this independent release was discontinued and these components
became tied to the O/S or product release cycles. While using a new name -
the ADO/OLE DB components are currently functionally equivalent to MDAC 2.8.
(And registered as both DAC6, and ADO, 2.x) Thus any application that used
MDAC components will run on Vista without installing any of these
components. Any attempt to install the MDAC or any of its OLE components
will error, and hopefully so - as you don't want to accidently over-write
the existing components.
OLE, a la COM, has provided numerous "security-risks", but no more so that
practically every other technology employed 10 years ago. Any application is
only as secure as it is written to be. "Security Risk" has to be address on
an application-by-application basis and the environment they are run in,
more affected by exposure of target surfaces outside the applications
themselves, and less by the technology used to implement them.
Note for the future:
The MDAC and all data access components - data access libraries, providers,
drivers, and OLE were originally under the MS SQL Team. These, while
related, are dissimilar services which have now been broken up. Jet and ACE
will now be handled by the MSAccess (Office) team. Providers and drivers by
the respective product team. OLE by the Windows Team.
Therefore if looking for an 'upgraded' ODBC driver or OLE DB/ODBC providers
check-out many 3rd party vendors or the vendor sites for your particular
database.
Also MS has announced that they do not (at the current time) have any plans
to provide ADO support for 64-bit applications. However, they also have
announced that they wouldn't advance DAO, then later did provide newer
components. They also announced they would not support ACEDB outside
MSAccess/Office, then later provided a separate provider for use by VB. So
... <g>
hth
-ralph
dave
"Ralph" wrote:
> .... <g>
>
> hth
> -ralph
>
>
>
ok, so would i expect a vb6 app that used the dao2.5/3.51 comatibility
library to fail to run on vista??
How about a vs6 c++ app that used dao which loaded msjet35.dll and
msrd2x35.dll??
I have started the rewrite, but am not far enough to try it all yet on
vista. but i have changed the vb6 app over to adodb classes and controls,
upgraded the 2 main databases from access 97 to 2000, and changed the main
c++ app from cdaorecordset/cdaodatabase to crecordset/cdatabase classes using
odbc connect strings... so now running on my xp development system the c++
app loads msjet40.dll and msrd2x40.dll along with a bunch of other
odbcji32.dll, msjter40.dll, msjint40.dll and probably some other database
related things. does that sound like i'm on the right track to get this
working on vista???
Ralph
>
>
> "Ralph" wrote:
>
<snipped>
> >
>
> ok, so would i expect a vb6 app that used the dao2.5/3.51 comatibility
> library to fail to run on vista??
>
The "DAO 2.5/3/51 Compatiblity Layer Library" was provided to support older
DAO 2.5 'code' to work with newer* Jet 3.5+ engine and Jet formats.
Surprisingly it will work on Vista - with some massage. If possible, avoid
all aggrevation and rewrite the Application to use DAO 3.6.
*If you consider 'newer' to sill be a 10+ year-old technology.
>
> How about a vs6 c++ app that used dao which loaded msjet35.dll and
> msrd2x35.dll??
>
This a slightly different case. The "msrd2x35.dll" is a translator dll which
allows newer Jet 4 applications to work with 'older' Jet engines and
formats.
>
> I have started the rewrite, but am not far enough to try it all yet on
> vista. but i have changed the vb6 app over to adodb classes and controls,
> upgraded the 2 main databases from access 97 to 2000, and
By removing DAO (using ADO) and by re-formatting all database to Jet 4. You
have removed any need for the libraries and components mentioned above for
VB. However, things are bit more complicated on the VC++ side as you have a
much larger assortment of data access libraries to chose from.
[Note: ADO uses OLE DB. DAO uses ODBC.]
>
> changed the main
> c++ app from cdaorecordset/cdaodatabase to crecordset/cdatabase classes
using
> odbc connect strings... so now running on my xp development system the
c++
> app loads msjet40.dll and msrd2x40.dll along with a bunch of other
> odbcji32.dll, msjter40.dll, msjint40.dll and probably some other database
> related things. does that sound like i'm on the right track to get this
> working on vista???
>
No. For accessing Jet formatted databases you should probably use the Dao
classes and not generic ODBC.
http://msdn.microsoft.com/en-us/library/ttc6chk1(VS.71).aspx
You can use ADO (with or without ATL support).
http://www.codeguru.com/cpp/data/mfc_database/ado/article.php/c6729/
You can use OLE DB directly. Best used with the ATL.
http://msdn.microsoft.com/en-us/library/5d8sd9we(VS.71).aspx
DAO is much faster when dealing with a Jet file locally. If the databases
(mdb files) are remote, and if you are using MTS or other COM+ services you
will find using ADO provides other advantages. OLE DB provides a deeper
element of control for some transactions, but IMHO is best reserved for
dare-devils and non-mainstream data sources.
hth
-ralph
Ralph
"Ralph" <nt_cons...@yahoo.com> wrote in message
news:e7u6JA5m...@TK2MSFTNGP02.phx.gbl...
>
I left out that for VB as well, DAO will provide better performance for a
local Jet-formatted database. It is also a tad easier to work with DDL using
DAO compared with ADOX. However, the ADODB controls are more feature-rich.
(DAO controls haven't been touched much since their introduction 20 years
ago).
-ralph
dave
"Ralph" wrote:
ok, that makes more sense. were there changes/fixes to the dao stuff for
vista in the last year or so? When i last tried this app on vista over a
year ago it failed with some kind of database access error. However when i
put it on again yesterday it ran.
I have other motives for going to generic odbc. There is a good chance that
this app will be combined with another one and we may want to allow users to
host the databases on other types of providers, desktop sql server, real sql
server, or oracle... i think odbc will make that simpler in the long run...
at least i already know how to set that up for switching data sources on the
fly.
Ralph
>
<snipped>
>
> ok, that makes more sense. were there changes/fixes to the dao stuff for
> vista in the last year or so? When i last tried this app on vista over a
> year ago it failed with some kind of database access error. However when
i
> put it on again yesterday it ran.
>
Impossible to tell without knowing the situation at the original attempt. If
you changed the Format to Jet 4, that would likely improve things.
Also Vista introduces stricter user security. This can be particularly
troublesome with file-base databases (a la mdbs) as they often require the
user to have full permission (read/write/execute).
>
> I have other motives for going to generic odbc. There is a good chance
that
> this app will be combined with another one and we may want to allow users
to
> host the databases on other types of providers, desktop sql server, real
sql
> server, or oracle... i think odbc will make that simpler in the long
run...
> at least i already know how to set that up for switching data sources on
the
> fly.
>
This is a tougher call that you might suspect, or that many articles may
have you believe. Creating a truely "universal data" application is not
easy. My advice - start reading. lol
All data access schemes utilize a "data stack". ODBC connectivity is only
one layer in the stack.
-ralph
司马格伦-MSFT
I'd like to mention that the data.xxxx.yyyy discussion groups, while
monitored, are not as actively monitored as
http://forums.microsoft.com/msdn/showforum.aspx?forumid=87&siteid=1
Which is the SQL Server Data access forum, the most active community for
data access questions, and most importantly, the area that the Microsoft
dev,test and PM owners themselves most frequently participate in.
If you want to get the most eyes on your questions, that's the place to be.
司马格伦-MSFT
http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/threads/
Pak-Ming Cheung - MSFT
But I have one clarification about the 4th message in this thread posted by
Ralph (@ Mar 2):
> Also MS has announced that they do not (at the current time) have any plans
> to provide ADO support for 64-bit applications. However, they also have
> announced that they wouldn't advance DAO, then later did provide newer
> components. They also announced they would not support ACEDB outside
> MSAccess/Office, then later provided a separate provider for use by VB. So
Actually, ADO is supported on 64-bit platforms. This is also TRUE for ODBC
and OleDB. Please read our Road Map at:
http://msdn.microsoft.com/en-us/library/ms810810.aspx
Thanks,
Ming.
WDAC Team, Microsoft.
P.S. We recommend customers to use the forum to ask questions in the future,
where you can obtain a faster response (Forum is at:
http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/threads/)