Items to be included to deploy

[matrik02]

In my program, I use ADODB Connection with Microsoft ActiveX data object 2.7 library,Microsoft Access Database, Code that contains picture filename location, Flash movie. I want to deploy my program on other computer. What Items or information should I have before using PWD so that my expectation is my program work well on target machine?

[si_the_geek]

For the database side of things (including ADO), you need to install MDAC and Jet as well as your program (I don't think P&DW can do them for you), and you can get both of those from the MDAC link in my signature.

You will also need to install Flash, but I have no idea how you should do that.

[Hack]

What installation and setup package will you be using?

[matrik02]

[QUOTE=si_the_geek]you need to install MDAC and Jet as well as your program (I don't think P&DW can do them for you QUOTE]

What deployment wizard can install the MDAC during installation the program on target machine?Can INNO setup able to do that?What MDAC and Jet? It is same? Where I can download JET? or If I download MDAC and install it, is it JET also included ?

[matrik02]

What installation and setup package will you be using?

I used default PDW provided by Visual basic. I have not try other setup package because I found that default setup package in VB is simple just clicking next button

[Hack]

Do you have a test machine you can run your install program on to make sure it works?

[Hack]

[QUOTE=matrik02]

you need to install MDAC and Jet as well as your program (I don't think P&DW can do them for you QUOTE]

What deployment wizard can install the MDAC during installation the program on target machine?Can INNO setup able to do that?What MDAC and Jet? It is same? Where I can download JET? or If I download MDAC and install it, is it JET also included ?

MDAC Downloads

[matrik02]

YES. I have test machine. If I download MDAC, Should I have download JET also? Because I use it in my code

Public Sub SPAD()
    Set condatabaseSPAD = New ADODB.Connection
    Set spadtable = New ADODB.Recordset
   
   condatabaseSPAD.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path & "\DBMS.mdb" & ";Jet OLEDB:Database Password=macres;"
   spadtable.Open "Select * from SPAD order by id asc", condatabaseSPAD, adOpenDynamic, adLockOptimistic
End Sub

[GaryMazzone]

The MDAC will take care of the Jet engine calls. There is no seperate download for Jet.

[Hack]

MDAC will handle the JET calls.

[GaryMazzone]

I beat you this time Hack. Are you getting solwer in your old age?

[si_the_geek]

You actually need to install Jet separately these days:

Q3: My application must have Microsoft Jet. However, Jet is no longer included with MDAC. Where can I find Jet?

A3: The Microsoft Jet components were removed from MDAC 2.6 and all subsequent releases.

(the Jet download is on the MDAC downloads page)

[Hack]

You actually need to install Jet separately these days:
(the Jet download is on the MDAC downloads page)

Really. When did this change?

I beat you this time Hack. Are you getting solwer in your old age?

The aging process rarely endows one with greater speed.

[si_the_geek]

Really. When did this change?

Apparently at version 2.6, I guess due to a large percentage of programs not actually using Access (or other Jet databases), thus not needing the extra files.

[matrik02]

You actually need to install Jet separately these days:
(the Jet download is on the MDAC downloads page)

Where you get that quote? This mean, from MDAC 2.6 and above should download JET?

[Hack]

Where you get that quote? This mean, from MDAC 2.6 and above should download JET?

Yes, from what si_the_geek is saying, this is true.

[si_the_geek]

Where you get that quote?

From the "Release Manifest" (which would normally be called 'ReadMe') on the downloads page.

This mean, from MDAC 2.6 and above should download JET?

Correct, you need to install MDAC (for ADO) and Jet (for using an Access database).

[randem]

Yes, JET support stopped with MDAC 2.5 this is well know. That was one reason for creating the Automatic OS Updater to handle those situation.

Handling that with Native PDW will be a task.

[matrik02]

How I can let the PWD setup install this two component JET and MDAC?

[randem]

Include MDAC 2.6 with PDW...

[randem]

But that is a shallow approach. PDW will not allow you to be selective. You still may need to manually deploy MDAC 2.8

[matrik02]

Could you suggest, what the package and deployment can include the folder and its files?

[randem]

You can't do it professionally with PDW unless you take the source code for PDW and re-work it. Not my choice... I have many times given you alternate ways of getting this done but you ignore them...

[dilettante]

One possible solution is to begin by targeting your applications to MDAC 2.5 functionality and avoiding DAO.

For the most part this isn't a problem. Later releases of MDAC consist primarily of bug fixes and optimizations. If you can use the feature-set of ADO 2.5 (which is almost all of even ADO 2.8's features) you start by selecting Microsoft ActiveX Data Objects 2.5 Library as your ADODB reference in your VB6 project.

On a machine with a later version of ADO installed this will actually be a TypeLib (msado25.tlb) that points to the newest version of ADO on the computer! This is very similar in concept to How To Develop with ADO Version 2.5 or Later and Install on ADO Version 2.0 which can also be useful.

Now you can compile and test on any machine that has MDAC 2.5 or later (and Jet 4.0) installed. When you build a PDW package though, you'll want to be sure you have Microsoft Data Access Components (MDAC) 2.5 Service Pack 3 in the PDW's "redist" folder so PDW will include that mdac_typ.exe, which is a version that will deploy Jet 4.0 for you.

When the resulting Setup package is run on a machine with a later MDAC, this won't get installed and your program will use the latest MDAC on the machine.


Caveat: To do this properly you'd really need to thoroughly test your application on a machine that has MDAC 2.5 as its latest MDAC. If your dev machine is WinXP for instance, there is a risk that your program works there but will trip over some bug in the real MDAC 2.5 components.

I do this kind of testing by running Win95 OSR2 with Platform SDK Redistributable: DCOM95 Redistributables installed (the more recent MDAC's require this). Then I run my PDW-created Setup package, and finally do my testing there.

You can do this without a second machine by using Virtual PC 2007 if your dev machine is WinXP Pro SP1 or later. Of course you'll need Win95 to install there. The nice thing though is you can get Win95 all set up and patched, then save the image so a rollback for new testing is trivial. Nice clean system every time!


There is usually no good reason to set a reference directly to an ADO version later than 2.5 anyway. This also neatly solves your MDAC and Jet deployment problem.

Note that these aren't hacks or workarounds. This is how you're supposed to be developing anyway. If a program compiled to reference ADO 2.6 runs on a machine with ADO 2.8 installed it uses ADO 2.8 in the same manner. It won't use ADO 2.6 because it isn't there! That's because the latest ADO installed is always installed as msado15.dll.

[dilettante]

Microsoft Data Access Components also details many reasons why an application installation should not aggressively install an MDAC later than 2.5 SP 3. Most of these can be seen in History.

[dilettante]

Apparently at version 2.6, I guess due to a large percentage of programs not actually using Access (or other Jet databases), thus not needing the extra files.

This was mostly because Jet 4.0 was released in versions tailored to different OSs for security, reliability, and performance reasons. Jet 4.0 comes preinstalled as part of (at least, if not before) Windows 2000, XP, 2003, Vista, and 2008.

[aikidokid]

@dilettante
I have been reading this thread, and in particular you post #24.

I am new to this, but if I get you right, you are saying if I point my app to Microsoft ActiveX Data Objects 2.5 Library then this would avoid the need for me to install both the MDAC files and the Jet files.
The app will be installed on MS XP machines or later.

[dilettante]

If you reference the MSADO 2.5 Library your program will actually make use of any version of ADO on the target system, as long as that system has at least ADO 2.5 installed.

Whether or not you choose to install a later version of MDAC is a different question. I'd advise not to, while others will disagree. There is no question we haven't seen the end of improvements though:

Description of the Jet 4.0 Database Engine update rollup for the release version of Windows Vista: May 11, 2007

However consider that over the life of your application the user's machine will see lots of updates to these components. If you think deploying MDAC gives you control or stability you're living in a fantasy world.


You can improve the odds of stability by avoiding the creaky dark corners of MDAC in your applications. Avoid deprecated features like ODBC or DAO whenever possible.

[aikidokid]

Thanks dilettante.

In general I am a noob at this and only a hobbiest programmer, so the next question may be obvious.
Does an operating system such as XP already install any versions of MDAC or Jet, or is this installed with say Access?

Also....
I have just downloaded Microsoft Virtual PC 2007, installed it, and then installed Win XP onto it, so now to learn how to use this as well I suppose.
Any obvious tips with this?

[dilettante]

Yes, everything starting with Windows 2000 or so has included a Jet 4.0 version and MDAC 2.5 or later.

Once again, feel free to install newer versions on your own machines, in most cases they are clearly improvements.

My concern is with people installing a new MDAC willy-nilly as part of widely deployed software. You can break others peoples' code, as in: An application that uses the OLE DB Simple Provider (Msdaosp.dll) with Microsoft Data Access Components (MDAC) 2.8 Service Pack 2 will crash with an access violation in Windows Server 2003 Service Pack 1. Even though your program doesn't use Msdaosp.dll, somebody else's on that machine might.

This is part of why MS is locking down MDAC (DAC) on Vista. Too many bad installer packages were breaking things.


With VPC, I've been avoiding putting the virtual disks on the main hard drive. Either use a second drive, or at least a second partition (D:, etc.), or even an external USB drive (though that can be slow). People have gotten into trouble with these images on their system drive. Some of Top Ten Tips for Using Virtual PC 2004 gets a bit exotic, but they're generally good tips. Watch #10 especially!

[randem]

aikidokid, Here is an app that was created for people like you in mind Auto OS Updater. It will install the proper MDAC/JET/DCOM for any OS...

[aikidokid]

It will install the proper MDAC/JET/DCOM for any OS...

Could this have any adverse affect on the end users machine with any of their existing software that may be using an older version?

[randem]

No, A machine may have multiple MDAC's installed...

[aikidokid]

Thanks randem

[seanwpb]

Randem,

Does the All versions Auto OS updater work for Vista? It didnt say on your site.

[randem]

Yes, it does work for Vista...

[dilettante]

No, A machine may have multiple MDAC's installed...

This is not true.

In the case of the ADO components subset of MDAC, you may see what appear to be available references to "multiple versions of ADO" but they are not that at all. With each MDAC release the new ADODB Library is installed as msado15.dll and a series of TLBs are installed that internally point to that new ADODB Library.

This is how a program compiled to use ADO 2.5, 2.6, 2.7, or 2.8 works on Vista, which contains ADO 6.0 for example. The same technique allows a program compiled against ADO 2.6 to work on a Windows XP system with 2.8 installed.

"There can be only one!" as they said in Highlander.

Installing the latest MDAC with your application might work fine. Certainly Microsoft hopes that the latest is the greatest. But MDAC releases do indeed contain bugs, and you risk breaking other applications by doing this.

Microsoft agrees, and now MDAC deployment by application installers is completely blocked starting in Vista.

[randem]

It is true, Many years of experience is the basis.

If you use Access 97 databases on your system you will need MDAC 2.0 for some things in the later MDAC's have been removed and some functions that your app may need will not work if just MDAC 2.8 is installed.

This is a time tested operation not a THEORY...

[dilettante]

If somebody is using ODBC to manipulate MDBs you only have one choice, either Access 97 or Access 2000 and later. By installing MDAC 2.0 you break the use of Access 2000 via ODBC on that machine.

How to revert to the Access 97 ODBC driver if MDAC 2.1 overwrites the Access 97 ODBC driver with the Access 2000 ODBC driver.

The hacks Microsoft suggests to get around this are at:

How To Have Your ODBC Jet 3.5 and 4.0 Applications Co-exist. Of course they put in disclaimers galore. They also offer HOW TO: Rename the Jet 3.51 ODBC Drivers Under Windows 2000 but that's such an onerous process it just shows desperation, which tells me that back at the turn of the century the problem you're trying to solve was considered quite serious.

The real solution is to stop writing Jet 3.5 applications and stop using the long-deprecated ODBC technology. Move to the Jet 4.0 OLEDB Provider, which can handle both MDB formats. Of course if you have an old application you need to support you don't have that luxury.

But I'm not sure that breaking Access 2000 applications to make Access 97 applications work is anything but an emergency stopgap in this day and age. I'd be worried that some guy writing a VB program using DAO and Jet 3.5/3.51 will use your Updater to make his program work and break a raft of DAO 3.6 Access 2000 programs on the same machine in the process.

[randem]

You don't install the MDAC's Willy-Nilly, You install the MDAC you need then re-Install the latest MDAC on the machine. Who would even think that just install the Earlier MDAC over a Later one????

Since YOU nor anyone else can control how other people write app or what they use, I offer a solution that will keep all the players apps working...