MDAC & Vista

Accept my apologies if this is not the right place for this topic.

We have a VB6 app which uses ADO and currently points to Microsoft ActiveX Data Objects 2.7 Library (msado27.tlb) as a reference when compiled. For reasons discussed in another thread in this forum (mostly that we're stating that our app is only compatible with Win2000 SP4 or greater), we do not ship MDAC with our installation package.

We're testing the installation of our app in house on three boxes: Win2000, XP SP2, and Vista Ultimate.

Data retrieval (for onscreen reports) seems to work fine for all operating systems, except that for certain data retrieval operations (just a few, but an important few), Vista always comes back with no data (Win2000 and XP both write the approriate data to the screen).

For the life of us, we cannot figure out why Vista would work most of the time when processing queries written for ADO, but not all of the time. More to the point, we have absolutely no idea where to start troubleshooting this issue. We're putting files in the "approved" locations, installation seems to be going fine, and the app starts and also seems to be running fine, except for this data retrieval problem.

Does anyone have any ideas what might possible be going wrong here? Or is this maybe and MDAC issue where a different forum would be more appropriate?

Thanks for any help.

Dan

I would suggest looking at MDAC online at the MS site. Vista comes with ActiveX Data Objects 6.0 so there may be backwards compatibility issues.

Also, where is the dabase located on the workstation? This could be a main issue

Would using the ActiveX Data Objects 2.8 Library solve the problem?

Quote:

---

Originally Posted by RobDog888

I would suggest looking at MDAC online at the MS site. Vista comes with ActiveX Data Objects 6.0 so there may be backwards compatibility issues.

Also, where is the dabase located on the workstation? This could be a main issue

---

Maybe I'm wrong, but one would think it should be easy to find something on the MS MDAC site describing how to update VB6 apps for Vista. Can't find anything on point, but will continue looking.

The database is installed to the User (old D & S) directory. Another odd issue that is related...we install a pointer to the database in the HKCU key when the app is installed. After installation this works fine when the user runs the app "normally". If they "run as administrator" however, everything falls apart. I've got to get that issue addressed too.

Quote:

---

Originally Posted by Hassan Basri

Would using the ActiveX Data Objects 2.8 Library solve the problem?

---

That's the first thing I'm going to try and do. We'll see...

Quote:

---

Originally Posted by DDJJ

Maybe I'm wrong, but one would think it should be easy to find something on the MS MDAC site describing how to update VB6 apps for Vista. Can't find anything on point, but will continue looking.

The database is installed to the User (old D & S) directory. Another odd issue that is related...we install a pointer to the database in the HKCU key when the app is installed. After installation this works fine when the user runs the app "normally". If they "run as administrator" however, everything falls apart. I've got to get that issue addressed too.

---

There is no guide to upgrading your vb 6 apps to vista as even with .NET apps its the same modifications being needed.

Security,different directory paths, and registry changes are universal changes no matter what language is being used.

Quote:

---

Originally Posted by Hassan Basri

Would using the ActiveX Data Objects 2.8 Library solve the problem?

---

Hassan, I may be a little premature...I've just been testing for a couple of hours, but it looks like going through and change the VB6 references from 2.7 to 2.8 may have done the trick.

Puhleeeeze!

Thanks to both responders for their comments.

Another odd issue that is related...we install a pointer to the database in the HKCU key when the app is installed. After installation this works fine when the user runs the app "normally". If they "run as administrator" however, everything falls apart. I've got to get that issue addressed too.



I could be wrong on this but I think...

Because of Vista's virtual user settings, when you run 'as administrator' the HKCU settings will be different from when you just run the app normally. It will use a different virtual store for each user. Maybe someone can confirm this.

Joey

Yes, this is true but of any OS version of Windows. If you store info in the HKCU then its the current logged in user just as the key name suggests.

"run as administrator" runs the app under the credentials of the Administrator which may in turn change the HKCU to be the Administrators instead.

If its a commonly shared data database then it needs to go into a publicly accessible folder/share.

When setting up the registry keys in your installer (in our case Tarma), does anyone know which additional keys need to be added to accomodate the "Administrator"? (or is this totally dependent on which installer you're using?)

Quote:

---

Originally Posted by DDJJ

Hassan, I may be a little premature...I've just been testing for a couple of hours, but it looks like going through and change the VB6 references from 2.7 to 2.8 may have done the trick.

Puhleeeeze!

Thanks to both responders for their comments.

---

So did it work?

I also use Tarma installer and I check "Must Run as Administrator" that way there are less issues during installation.

So far it it apears to be working fine.

I there a checkbox for "Must run as Administrator"? Or do you mean the installation level under Intsaller Options?

If multiple users are using the same box, I want to make sure that each user has a separate registry key. so I need to play with htis a bit.

Dan

Quote:

---

Originally Posted by DDJJ

So far it it apears to be working fine.

I there a checkbox for "Must run as Administrator"? Or do you mean the installation level under Intsaller Options?

If multiple users are using the same box, I want to make sure that each user has a separate registry key. so I need to play with htis a bit.

Dan

---

No, I meant the installation level under Installer Options.

If you are using HKEY_CURRENT_USER they should each get their own keys (unless all your users log on using the same username).

My VB6 program checks if a db exists in the application directory. If not, it creates it (in the application directory). Running on Vista, I have a problem. It keeps coming up with a message "database already exists." A check of the application directory comes up empty. It's not on the desktop either. Anyone know where it is?

Vista doesn't allow files to be written in the program files directory. When a call is made to create a file in the program files directory, it's created in another place and referenced but I can't remember where that folder is at the moment. I'm sure someone knows the location. You should try to create the db in the users\allusers folder. This will eliminate any problems with users accessing the db and your program creating the file.

It is no longer feasible to install any shared files in the Program Files directories because Vista doesnt allow it. Sure you can do it but like you are finding it gives issues when done as usual.

The concept is File Virtualization. Vista creates a virtual shortcut located in the Program Files directory in the folder where you are trying to install the file. The shortcut points to the "VirtualStore" directory under the user profile:
C:\Users\UserName\AppData\Local\VirtualStore\Program Files
When the app tries to read and write Vista makes it think that it is reading and writting to the Program Files\Whatever Directory. Virtualization is only a temporary workaround that should not be relied upon as it has been stated by MS that it will be done away with in the future.

The long term solution is to place any file(s) that are to be shared across all users to the "C:\Users\Public" shared directory.