Vista issue? Database is not being updated.

[rlawrence]

Hi,

Once again I am turning to this forum for possible answers to a complicated situation. I have a VFP application that I have supported and reissued for 20 years now. I have successfully installed on many Vista systems. Recently, however, a user in Greece was installing on a Vista system. The installation went fine, but the registration procedure (which writes encrypted information to the database) wouldn't stick. The next time the user entered the application, it was as if the registration was never done. There were some other bizarre behaviors as well--all making me question whether the data was actually being saved.

Now, I've run into this type of situation before. Suspecting a security problem, I check the security settings for the files and folders in question and all seemed O.K. By the way, the database was installed in the users Documents folder. (You can check out a rather lengthy conversation on this in thread184-1539853.)

We uninstalled and reinstalled the software--making sure to run the installation in administrative mode. We also tried knocking out the anti-virus software while testing.
We got the same result.

Finally, in desperation, the technician who was assisting in Greece installed a new copy of Windows 7 on the machine. My application then installed and ran without any issue.

My question is: What on earth could have been getting in the way? Is there something in Vista that I have failed to understand? Like I said, there are several successful Vista installations. My own development machine is on a Vista system.

By the way, I asked Toshiba (the manufacturer of my clients machine) if someone there might help me to troubleshoot this on a machine with the same configuration. Their technician simply said that there was no problem with their software and gave me the number for Microsoft.

Any ideas would be appreciated.

Ron

 

[DougHennig]

Hi Ron.

It sounds like the user was running the application under different user accounts. Since you're putting the data files in the user's Documents folder, that would explain why the data "disappeared" between runs.

For example, if the user is a normal user, they have to elevate to an admin user when the app is installed. If the installer launches the app, the app is running under the admin user account. Any information they enter is stored in the admin user's Documents folder. When they exit and re-run the app, now they're running it as their normal user, so now it looks in their Documents folder and doesn't find the previously entered information.

This may not necessarily be the issue, but it does sound like it.

Doug

 

[rlawrence]

Thanks Doug,

I did have a similar thought; but the technician there assured me that the user account was the only one on the machine. It was an administrative account.

Of course, Vista tries to protect us from ourselves, making you verify that you want to run an administrative function (like installing new software). We wouldn't have been able to "Run As Administrator" if the account was not an administrative account.

The application sets a path to the database. We moved the users old data into place and the application recognized it. Still, the registration didn't hold; and as I mentioned, attempting to perform other transactions wasn't working reliably either.

Still, there's something in your suggestion. The whole "My Documents" thing is a little strange--especially when you consider that it's actual location in the file system has changed with EVERY version of Windows.

I can't help but wonder if there is a situation whereby it seems like I'm looking at the data, but really only looking at a copy.

Ron

 

[Olaf Doschke]

Do you mean writing to the registry, when you say "the registration didn't hold"? Also, are OCXes or COM classes involved?

If the pure phenomenon of missing data was not because of different user accounts, finding the right path from eg a registry key may be the culprit.

As even admins need to confirm administrative tasks in Vista, your setup might be able to write to system registry branches you may not read what you wrote during setup when your app finally runs without being run as admin. See

http://msdn.microsoft.com/en-us/library/aa965884(VS.85).aspx

Reading keys, which are virtualized when written can mean you get some "mixture" of the real key and a virtualized value. It's explained in more detail in the MSDN.

Bye, Olaf.

 

[rlawrence]

Thanks Olaf, but no. This is strictly a database update. Flat tables--no buffering involved. FLUSH commands used throughout.

Ron