Vista 64 And DAO - Need Some Advice

[Knightlite]

Hi,

I need a little advice. I have several programs written in VB6 (took me 5 years to write them) that use DAO and Access. I have heard that the 64 bit versions of Vista will not run my programs, so I have to upgrade them. What is the best way to do this?

If I stick with VB6 can I still use an Access Database file with ADO and would this work with Vista 64 bit?

Should I just rewrite everything with VB 2005? (not looking forward to doing that.)

And can an Access database file still be used with VB 2005 and still be ok with Vista 64 bit?

You comments would be greatly appreciated.

Knightlite

[si_the_geek]

You should never have created VB6 programs using DAO (in the help it explicitly said something like "only use DAO for existing projects, use ADO for all new ones").. but then for a couple of years I didn't listen to that either!

ADO in VB6 is fine, and will be supported for a while yet. It would also work if you re-write the programs in VB 2005 (VB.Net) using ADO.net, which will be supported for longer.

One thing to note tho is that VB6 isn't going to last forever (it wont be supported for the version of Windows after Vista), so moving to .Net would be a good idea if you want these programs to last a while.

[RobDog888]

64 bit Vista should be backwards compatible with the standard 32 bit version.

ADO 6.0 is defaulted in Vista and you really shouldnt install DAO on it (more then likely will have compatibility issues).

Like Si posted, you should be using .NET for guarenteeing longevity of your app.

[si_the_geek]

...you really shouldnt install DAO on it (more then likely will have compatibility issues)

Indeed - the trouble is that DAO itself is not 64 bit compatible (see MDAC "obsolete" info).

[Knightlite]

[QUOTE=si_the_geek]You should never have created VB6 programs using DAO (in the help it explicitly said something like "only use DAO for existing projects, use ADO for all new ones").. but then for a couple of years I didn't listen to that either!<<<

I know, I was out of control :-), but at that time I was trying to port applications to VB6 from VB3 and it seemed to be the easiest way to do it. I just took the easiest way out without having to learn and rewrite everything in ADO. I guess that was a mistake.

>>>ADO in VB6 is fine, and will be supported for a while yet. It would also work if you re-write the programs in VB 2005 (VB.Net) using ADO.net, which will be supported for longer.<<<

Can I still use an Access Database file with ADO.net, or will that mess things up?

Thanks again for your quick response.

Knightlite

[RobDog888]

The quickest and easiest way to solve the issue is to convert the app to use ADO. Nottoo much difference between DAO and ADO but to go to .NET is a major change.

[Knightlite]

[QUOTE=RobDog888][color=navy]64 bit Vista should be backwards compatible with the standard 32 bit version.

Does that mean there is a shred of hope that the DAO sofware will work on 64 Bit? Can the 64 bit version of Vista be made to run in 32 bit mode?

I will be doing the upgrade, I just want to see if I can buy some time.

Knightlite

[RobDog888]

You can still use Access in ADO.NET.

[si_the_geek]

I know, I was out of control :-), but at that time I was trying to port applications to VB6 from VB3 and it seemed to be the easiest way to do it. I just took the easiest way out without having to learn and rewrite everything in ADO. I guess that was a mistake.

That sounds familiar!

Does that mean there is a shred of hope that the DAO sofware will work on 64 Bit?

I doubt it, and I wouldn't want to take the risk.

When Microsoft say something is "unsupported" they basically mean that it might work, but they aren't promising anything.

..something being "obsolete" (like DAO is now) is far worse. It is unlikely to work with 'modern' software, and may even cause noticeable problems (eg: it may delete some/all of your data!).


As they have explicitly stated "It will not be available on the 64-bit Windows operating system." I presume it had far too many issues to even consider finding solutions.

[Knightlite]

I guess the quick fix right now is to update my software that I have so at least the 32 bit versions will still work, then update the VB6 versions to ADO which I know nothing about, and then start working on Visual Basic 2005. Would the Express version be okay? I have that loaded.

Thanks again for you help. I appreciate it.

Knightlite

[RobDog888]

Express should be fine until you outgrow it. No need to spend money yet when there is a lite version for free.

[Knightlite]

Thank you again. I appreciate your advice. :-)

Knightlite

[Keithuk]

Ok I know this is an old thread but I have the same problem. I've made an app that uses DAO for a VW forum, I know its old but thats what I'm used to.

The Admin on the forum has tried it and he has a couple of problems COMCTL32.OCX is not correctly registered. Now I know it only has to be registered for VB IDE as I've made many apps for friends along with any necessary ocx files and told them just to put them in your Windows\System32 folder and they all run without a problem. I told him to

Run: regsvr32.exe COMCTL32.OCX and make sure he sees the return message. DllRegisterServer in COMCTL32.OCX succeeded.

Is there some x64 compatibility with COMCTL32.OCX?

He's using Vista x64 and as the database uses dao360.dll which is from MDAC 2.8. There is no x64 version of this, there are also other comments that is not backward compatible with x86 because it says it will corrupt the registry. I've searched the web for this problem.

I don't fancy converting it to ADO but even if I did is there an x64 version of ADO?

[dilettante]

An x64 version of DAO would not help you because your program is still compiled for x86.

DAO360.DLL is supported and will still work as is COMCTL32.OCX but in both cases the software has to be deployed properly. DAO360.DLL has not been part of MDAC since MDAC 2.5, and it is now serviced through Jet 4.0 service packs because Jet was not included in MDAC after 2.5 either. Depending on the program you might need more than just DAO360.DLL too, such as data binding and formatting libraries.


A 32 bit setup running under 64 bit Vista or Windows 7 will run under the WOW64 subsystem, and it will experience filesystem and registry redirection so that "System32" files go into "SysWOW64" where they need to be and 32 bit COM registration will go into the 32 bit part of the registry as well.

You can also do this by hand but it's a bit clunky and non-obvious. Suffice it to say there are two versions of regsvr32 on a 64 bit system and you need to run the right one.


It is far cleaner just to create a deployment package and use that. Successful deployment across the wide number of Windows versions that exist now has become a tricky matter, but the easiest path is usually to let Windows help you rather than fighting it.

[Keithuk]

Thanks for the info dilettante

Isn't there some compatibilty tab the exe properties like in WinXP where you could set it to run under WinXP 32bit?

So are you saying that COMCTL32.OCX should go in the SysWOW64 folder?

DAO360.DLL is still part of MDAC 2.8 SP1

Depending on the program you might need more than just DAO360.DLL too, such as data binding and formatting libraries.

It just uses a database that I've compiled into the exe which it extract when its first run. Plus COMCTL32.OCX for the Toolbar, Statusbar and ListView. There is nothing in the References thats missing.

So do you think it would work if I made an installation package with Inno Setup not P&D Wizard as thats 11 years old and you can have problems installing on to a modern OS?

Which two versions of regsvr32 are there?

I just told him to Run:

regsvr32.exe COMCTL32.OCX Make sure you see the return message. DllRegisterServer in COMCTL32.OCX succeeded.

[dilettante]

There is a 32 bit and a 64 bit regsvr32.

MDAC is no longer relevant, Windows DAC has replaced it in modern versions of Windows.

If you create an installation package there is no need to create oversized EXE files with enbedded files.

The PDW still works more than adequately for many purposes. 64 bit Windows actually recognizes PDW's setup.exe and makes special allowances so that it installs properly.


Your real problems will come from doing things like using read/write data files in the program's folder or writing to protected parts of the registry. Normally you should not need to set any compatibility options manually.

Setting WinXP Compatibility does little more than set a "version lie" feature in several system components, so that programs which check which Windows version they are running on get back false results saying they're running on Windows XP. Version Checking (Just Don’t Do It)

New programs should have an application manifest that indirectly states they follow the rules. This indirect statement is implied when you have a trustInfo entry in the manifest. Without this Windows will apply a number of AppCompat shims without user intervention, which may cause some confusion for the user but your program will still run. With this your program will abort if it tries to break the rules.