Vista Headaches

[wunder]

Hi all- sorry to post so much as a newbie...

Our company has been selling software since 1990. Each new Microsoft OS has presented its own set of issues, but I think Vista may be the biggest PITA of them all.

Our software programs all use Microsoft Access databases to store data. We need all users of a computer to share the same database.

Since Windows 95, we've stored the database along with the program in the program files folder.

Along comes Vista with its Virtualization. Data stored in the program files folder is copied out to the virtual folder which causes all sorts of problems with our software.

So, I started looking for a new home for the database. At first I moved it to the users\application data (programdata, cisdl=35) folder. However, it turns out this folder can be virtualized as well. Also, it's hidden by default in Vista which isn't very good for tech support staff.

Then I started using the users\all users\documents (users\public, cisdl=46) folder. This works great in Vista, but apparently in many businesses which have XP this folder is often not read/write by default!

I can't use the 'my documents' folder because if there are multiple people using a single computer, I need all the users to see the same data.

At this point I see 3 options for us:

1) Use program files folder for all computers except vista and use the users\public folder for vista. I'm not crazy about that because our tech support has to deal with different locations on different OS's.

2) Set permissions on the users\all users\documents folder for XP. I started experimenting with this using the CACLS command, but I'm not sure this is going to work unless the user is a full admin.

3) Install the whole works to the root of the user's C: drive. Obviously a method of last resort! We have a couple of pre-win95 programs that still do this and surprisingly they both work great in every OS from Win95 through Vista!

Sorry for the long note. If anyone can think of a better solution, I'm all ears!

[Lorne]

Couple semi-random ideas:

Have you tried All Users\Application Data?

Maybe let the user choose the location for the database, store that location in the Registry (or in a config file) and have your application read the database location from there?

[pww]

I solve this by giving Full Control permissions to Everyone for the program's install dir, using a slightly modified version of this

http://www.indigorose.com/forums/showthread.php?t=16092

As I do it from the installer that is always guaranteed to be run by admin (and in Vista - elevated), it works OK - my app can write to install dir without problems, no matter which user started it. Non-admins can modify/delete files created by admins etc. on any Windows, and there is no virtualization.

In Vista, problems may appear only if you set permissions not at install time but later, if the folder is already 'virtualized' - then it always uses the files from the virtual store. The solution in such case is to delete the files that belong to your app from the virtual store, and everything goes back to normal.

If I correctly remeber, writing directly to drive root isn't allowed for non-admins in Vista, though I may be wrong.

[wunder]

Couple semi-random ideas:

Have you tried All Users\Application Data?

Yes and this works all the time in XP and SOME of the time in vista. We've run into instances of this folder getting virtualized as well!

Maybe let the user choose the location for the database, store that location in the Registry (or in a config file) and have your application read the database location from there?

This may be what we end up doing. I think we may end up going to the "my documents" folder, but allowing the users the option of changing this at installation time so they can have a shared database rather than individual ones.

[wunder]

I solve this by giving Full Control permissions to Everyone for the program's install dir, using a slightly modified version of this

http://www.indigorose.com/forums/showthread.php?t=16092

[snip]

If I correctly remeber, writing directly to drive root isn't allowed for non-admins in Vista, though I may be wrong.

I read that thread with interest. I'd like to go with the 'standard' folder going forward, but I'm not sure there is such a thing for my situation.

I wouldn't be storing files in the root, but off of a folder created by setup factory at installation time, so that seems to work fine, but it seems like that would be breaking all the standards in the book.

[jassing]

Yes and this works all the time in XP and SOME of the time in vista. We've run into instances of this folder getting virtualized as well!



This may be what we end up doing. I think we may end up going to the "my documents" folder, but allowing the users the option of changing this at installation time so they can have a shared database rather than individual ones.

The ProgramData\ folder should be where you put things that "change"
(data files etc)
I was doing installer work for a company that has a application based on FileMaker (Similar to access in that the code is stored with the databases)

I guess FileMaker doesn't easily allow the main program to be in a different directory than the user-database files.

Another customer developed something in Access -- they wanted the installer to just refuse to run if vista didn't have UAC disabled; vs 'fixing' the application...

Vista definately is a pain; but FWIW; we "knew it was coming" -- XP had all the directories "in place" -- vista is just enforcing that we use them.

[wunder]

The ProgramData\ folder should be where you put things that "change"

That's the theory I was going on. However, we found that after installing our software on some Vista computers, this folder was also being Virtualized. What a pain.

We knew it was coming just like Hurricane Katrina. With about the same results.

[jassing]

That's the theory I was going on. However, we found that after installing our software on some Vista computers, this folder was also being Virtualized. What a pain.

We knew it was coming just like Hurricane Katrina. With about the same results.

Since a lot of my (suf7) consulting biz is vista related; I'd be interested to know if you found out why that directory wasn't working reliably.... I've not run into it.... but I always believe -- if it happens once; it will happen elsewhere.

[wunder]

I didn't find out- we sell directly to consumers, so we didn't have access to the computers for analysis. But it definitely happened to more than 1 customer. But not all. Very frustrating! Of course, testing using Virtual PC would never show the problem in our lab.

Right now the consensus is that we're going to 'give up' and switch to the 'my documents' folder. We'll have to make changes to our applications so the database path can be changed. Not necessarily a bad thing to do anyway.

[jassing]

Did you use the user level or app level for data?

For one client, I wrote a fairly in depth (IR awarded it the "pushing SUF7 to the limits and beyond" award) "support tool" to gather information about a users system, generate a text file with a signature to deteect tampering; and optionally post it to a website for tech support.

Very low impact on the user and has proven very useful for diagnosing issues. You might want to consider a "data gathering" tool for yourself.

I use the "single click" ultravnc for customers that are willing to let me have a remote control connection -- I'd say well over 70% allow me in; the remainder is evenly split between "IT won't allow it" and "I don't trust you" sort of explinations.

If I encounter something like this; I'll be sure to make a note of it and post here if I discover anything useful....

-josh

[wunder]

Did you use the user level or app level for data?

I'm not sure I understand- do you mean user/public vs programdata? I actually tried both. user/public works fine in Vista, but fails in some XP network setups. programdata works on many but not all vista systems.

Very low impact on the user and has proven very useful for diagnosing issues. You might want to consider a "data gathering" tool for yourself.

Already have one, but it doesn't display user rights on files. That would be a nice trick, but I don't know how to do that at the moment.

I use the "single click" ultravnc for customers that are willing to let me have a remote control connection

Whoa. I think I now owe you a six-pack. I used VNC many years ago. I didn't realize they now have a version that can punch through both firewalls and doesn't install anything on the client. That's freaking awesome.

[jassing]

Whoa. I think I now owe you a six-pack. I used VNC many years ago. I didn't realize they now have a version that can punch through both firewalls and doesn't install anything on the client. That's freaking awesome.

Nex time your out in Washington state; I'll let you buy me a pint.. ;-)

-josh