Installed database location? 3

[rlawrence]

Now, I've been at this for a while, so this question seems a bit rudimentary. However, I'm now faced with creating a Vista compatible installation. That means nothing that changes should reside in the program files folder. My installation kit installs an empty and a sample database for my application. My question is: Where should my installation procedure put these things--particularly on a Vista machine?

There are several other files that can be updated by the application: CONFIG.FPW, FOXUSER, user preferences table, and report forms.

My first thought would be to install these to a structure under "My Documents". (Even that is different under Vista.) Ideally, the same installation procedure would work for older versions of Windows as well.

Installing to My Documents will, of course, install the data files to the user's profile. That will work fine for most people, but if someone else logs into the machine, they won't see the data.

I know that there is an "AppData" folder, but I really think this would throw most of my users. AppData feels like forbidden territory (though I suppose the Program Files folder should be forbidden as well).

I stress to my users that they need to understand where their data is so they can back it up and restore it if necessary. Program Files and "My Documents" have reasonable and fairly visible paths. AppData does not.

So, what are others doing with your installation procedures?

Thanks for sharing,

Ron

 

[DSummZZZ]

You should go read this article by Doug Hennig:

http://my.advisor.com/articles.nsf/aid/18897

Very informative.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Ron,

Is there any reason why you can't simply create a new folder specifically for your database (and similar files)? If the data is to be installed on a stand-alone machine, the folder could be off the root of the C: drive. If it is mutli-user app, it would be on a network drive.

That seems to be to be an obvious solution, unless I'm missing something.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[rlawrence]

Thanks Dave.

Excellent article. I guess my question wasn't as rudimentary as I thought. What a can of worms though! Also, the explanation doesn't do much for my "keep it simple for my users" approach. :-(

Still looking for thoughts on how others have approached this.

Ron

 

[DSummZZZ]

Vista is definitely a whole 'nuther critter.
I did like Mike suggested on one of my apps and just made an install folder off the root of C: drive.
Since I have an .INI file that saves configuration changes, I also put that in the app startup folder instead of the Windows folder. Vista is a big PITA when it comes to updating files.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

Mike,

this solution would surely work, but somehow undermine the reason there is an AppData directory in windows.

It seems Vista now only allows readonly data in Appdata, which might be fine for some apps but surely not database apps.

A solution that works and is not specialiszed to Vista is categorizing application data rather like documents and installing the apps database in an app sub folder within the users documents folder, if it's for a single user desktop app.

It's still undermining the reason for the different local/roaming userspecific/public appdata directories in Vista, but you don't need to handle different OSes with a different setup and still your database goes into a windows specific managed directory and not "into the wild", like a seperate C:\myappdata would be.

Bye, Olaf.

 

[rlawrence]

I rather agree with Olaf. While the C:\MyappData folder is clean, Doug Hennig's article specifically warns against it. I like tot think I take a wider view of things than just my application.

So far, I have actually been working toward Olaf's suggestion. I've completed a fair amount of work on an application to set up the database and accompanying files based on similar logic.

It bothers me, however, that an installation into the users documents folder will work fine for the user who installs the software. It won't work so well for anyone else without a little "IT" work. I suppose in a multi-user environment, a little "IT" work is in order anyway.

I'm surprised to learn that the AppData folder is intended for Read-Only data? Why wouldn't Read-Only data go into the Program Files folder? What, then, is the purpose for the seperate AppData folder, which--as I mentioned above--seems less accessible anyway?

I'm mostly interested in how others have addressed this situation. I really appreciate the discussion.

Thanks all for taking the time.

 

[rlawrence]

Any thoughts on the pros and cons of installing to the Shared Documents folder?

Ron

 

[Olaf Doschke]

One point is that not only the structure of the system folders changes, also the Functions determining those folders changed. And it was not done nicely and downwards compatible in my knowledge.

See the vista compatibility blog:

http://blogs.msdn.com/vistacompatte...getknownfolderpath-and-the-knownfolderid.aspx

until Vista: SHGetFolderPath

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

since Vista: SHGetKnownFolderPath

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

Heres a list of the new FOLDERIDs that should be used. It also shows to what CSIDL these compare.

You can se that CSIDL_LOCAL_APPDATA, which was %USERPROFILE%\Local Settings\Application Data is now in USERPROFILE%\AppData\Local.

CSIDL_COMMON_APPDATA, which was %ALLUSERSPROFILE%\Application Data now is %SystemDrive%\ProgramData

CSIDL_APPDATA, which was %USERPROFILE%\Application Data, now is %USERPROFILE%\AppData\Roaming

And you know what? You can write to C:\ProgramData and within the Roaming or Local subfolders of AppData on Vista. So also when you used CSIDL_APPDATA or CSIDL_LOCAL_APPDATA so far, all is well. If I'm not fooling myself as admin.

Don't aks me why, but I had in mind there was some quirk, maybe that was before Vista SP1 or within a localized windows version. Maybe that quirk simply is a problem of the Installshield Express, that comes with VFP(9) and it installs appdata somewhere else, even if you choose APPDATA/COMMON_APPDATA.

Bye, Olaf.

 

[rlawrence]

Thanks Olaf,

Yes, my head is spinning with all of these references. I have been wading through the file system and the registry for both XP and Vista. I've also been looking at SHGetFolderPath.

Actually my VFP startup app uses WSHShell.SpecialFolders() based on a posting I found for updating shortcuts:

Credit for this code snippet: Erik Gomez,

http://www.foxite.com/archives/how-to-create-a-shortcut-programmatically-f-0000047237.htm

There might be better ways to do this, but this was pretty easy to implement. (Thanks Erik!)

So now, it sounds like AppData may be the right choice, at least to provide visibility to all users on the same machine?

I'm actually using Wise Install. Currently searching for how it is able to reference these "special" folders.

Ron

 

[Olaf Doschke]

If your Installer is able to provide the special folders for your setup is one of the most important things. WSHShell.SpecialFolders() does not provide all of them, AFAIK.

SHGetFolderPath is what installers should use in creating a setup working on Vista, XP and older, SHGetKnownFolderPath would of course only work on Vista. If you can choose the destination OSes and use different branches of the setup according to each OS, then you're best off.

Providing visibility to all users on a local machine would mean using CSIDL_COMMON_APPDATA. Wise may display it as COMMON_APPDATA or common application data, you should be able to see what real folder it would use on your development OS, if that is c:\ProgramData on Vista everything is fine.

I'd perhaps take a look at

http://fox.wikis.com/wc.dll?Wiki~CategoryInstallers

and Inno Setup, if Wise does not provide what you need. But I'd say even if the Wise version is old, it should offer special folders and the common appdata folder, as that goes back to windows 98 perhaps even 95.

Bye, Olaf.

 

[DougHennig]

Hi Ron.

The approach I've been taking lately is to use a Data subdirectory of the program folder for some files the application needs to write to and can reliably find regardless of who logs in. I specifically making Data read-write at installation time, since normally it's read-only. I then ask the user where they want their data files to go and store that location in an INI file in the Data subdirectory. This gives the benefit of allowing the user control over their data files; perhaps they want them stored on a server or they could go in the Data folder as well.

I blogged about this a while ago:

http://doughennig.blogspot.com/2007/12/where-should-data-go-in-vista.html

Doug

 

[rlawrence]

Thanks Doug,

Great articles, by the way. Actually, I already do much of what you recommend. In previous versions, I simply placed the data folder in the program files folder because it was a simple and consistent place to find it. However, I have provided the means (both through CONFIG.FPW and an INI file) to allow the user to locate the data anywhere they want. This seems necessary for any multi-user installation.

I have recently been working on a wizard utility that allows the user to go through a litany of operations to relocate and set up their database for operation under Vista. I want the same process to work for XP/2000 or earlier versions of Windows.

My current plan is to install everything to Program Files\myapp folder, but then ask the user where they want to locate their data. The application currently suggests an application folder under My Documents. (I've noted my concerns about this above.) But the model of placing everything in the program files folder, and then copying changeable files to the working directory seems like a good approach. That leaves the originals in an easy (and consistent) place in case a user totally botches a file.

This list of files has grown over the years. I mentioned config.fpw and an INI file. Of course there's the database. But there are also report forms, default.fky, foxuser, and my own user preferences file. And both Foxpro and my application write data to temporary files.

I am porting all of these to an application data folder, and placing the database in a subfolder by default. The temp files and error log get written to a Temp subfolder.

There's a fair amount to this process, and the development has left me wondering whether I am taking the best approach. That's why I decided to ask some others. It sounds like I am not far from the mark. Still up in the air about whether to use CommonAppData, My Documents, or leave the data in the program files folder as you suggest. With all of these different files, it might be that more than one location should be considered.

As I'm writing this, I think I'll put a stake in the ground for the sake of others. Please feel free to comment on my logic.

Most of my users are single-user installations. Most would rather not be bothered with the details of setting up a new database. And probably most are the only ones to use their machines.

I ruthlessly harp on my users about knowing where their data is and backing it up regularly; but, some still don't, and there have been some tragedies over the years. :-(

Still, I think for most, not having to decide where to put things and placing the database in an easy-to-find location are still top considerations for my approach. This is what lead me to the My Documents folder to begin with, and I think I'm going to stick with it.

For multi-user installations, someone on site will have to decide where to locate their database and how to share it with the rest of their network. So, they will generally have the wherewithal to decide on a good location for their data.

You know, I'll bet that NO ONE will choose CommonAppData.

This all makes me wonder just what Microsoft has in mind for the setup of any database application.

Hope this discussion is useful for others as well.

Thanks to all for your contributions,

Ron

 

[Olaf Doschke]

I agree that users will rather not look into Appdata folders, not local, roaming or common. In that respect "My Documents" would give the database files a better "visibility". But do you really want the users to fiddle with your DBC and DBFs?

Also consider, that the data alone is worthless without the app and roaming data could mean diversification of the local remains of a DBC and what's stored on the server profile of a user.

So for a single user install I'd rather opt for user specific Local Appdata. If a user want's to use the same database from different computers, it's already kind of multiuser, you need a central place for the data, if you don't want a mess due to overwriting the database by roaming profiles, outdated server profiles etc. I'd not solve the roaming single user app by storing data into the user's profile.

By the way, MS does think about database applications, that they use an SQL Server Instance, if you want the short answer.

It's different again, if the app is installed on a terminal server and used remotely by several users. There I'd rather opt for Local common appdata, like in a local install for all computer users.

Putting the database somewhere it's roaming is only good if the application itself does roam too, eg like software not fully installed, but working from a USB drive (portableapps), and in that case I'd store the data to the app folder and again not in a users profile.

So for a normal desktop app, I'd let the setup ask if it's an install for all users or the user installing the app (that's even an option of the ISE version coming with VFP) and depending on all or single user put data in common app data or userspecific local app data. At application start you can determine both folders and look for your database.

Regarding backups you'd put an option in your app for that, close all data and use copy file for the backup or restore, perhaps also zip, eg with craig boyds vfpcompression.fll.

If the user installs software on two computers (and you allow that) a nice feature could be merging data from several databases, depending on the application and nature of the data that ranges from being easy to being impossible.

It also depends if the database of your app is rather like a document (eg there can be several databases the user selects from and a user might create a new empty one at any time) or you have only one database for everything.

Bye, Olaf.

 

[rlawrence]

Hi Olaf,

Just when I was feeling like I had an answer...

First, you asked if I want users messing with the DBC's and DBF's. I think the answer is, "Yes". This has to do with my philosophy about handling the data. My recommendation to users is to back up their data to a CD-R. Again, most of my users are challenged even by this basic file system operation. Using a backup utility for most is asking a lot.

What I tell them is that having their data backed up to CD's keeps them from overwriting old data. If their computer melts down, they can take their last CD backup, go to any other machine, download the software, load their data with a file transfer operation they understand, and be up and running again in minutes. The CD's also keep them from writing bad data over good. That has happened with Zip Drive users in the past.

I've resisted providing a backup utility because I think it provides a false sense of security. If your hard drive goes--excuse me--WHEN your hard drive goes, I don't want their backups to go with it.

So, yes, I want them to know that the tables in their database must be kept together, in sync' and backed up to a safe medium.

So for a single user install I'd rather opt for user specific Local Appdata. If a user want's to use the same database from different computers, it's already kind of multiuser, you need a central place for the data, if you don't want a mess due to overwriting the database by roaming profiles, outdated server profiles etc. I'd not solve the roaming single user app by storing data into the user's profile.

I'll admit that I don't have a firm grasp on the implications of "roaming". However, let me see if I can probe this a bit.

I'd say that 80% of my users can be described as novice computer users. So, they will likely be the ONLY user on their machines. Even if they are not, they are likely to be the only user of my application on their machine. So, putting the data where they can easily find it is important. These users are not likely to want or need to access their data from a different location or account.

As soon as someone decides that they do need access from another machine or account, then that means that they need to be aware of a number of things--like how to set up a new account, and the virtualization of their documents folder.

In other words, as soon as someone decides that they need to make their data available to someone else, they take upon themselves the responsibility of understanding how they are going to do that. At that point, the user assumes ownership for locating the data where multiple users can see it. Before then, they just want the darn thing to work.

Unless I am missing something, I think My Documents should work just fine. So... am I missing something?

Thanks again for your thoughtful responses.

Ron

 

[Olaf Doschke]

For the normal case of a home user with a single computer and no server, no domain, there is no roaming of course, so there it really only does matter if they set up several accounts on their computer or everyone logs in as Administrator or the one user they set up at XP/Vista installation.

"My Docs" then is fine.

But still I'd consider, that the "installation for you or all users" would be an easy question to them. Even if they don't understand the implication this has, there might be only their account on the computer and then it doesn't really matter if it's common app data or local app data for that single account. Only later, when their knowledge about windows enhaces and they find how to setup a second account and the advantages this has, you still could copy the data to the appropriate folder.

You are doing good in suggesting them to know a little about the file system and how to burn files on disk. But at least from XP on you can simply copy files to the system folder for burning CDs and the OS will prompt that there are files ready to burn to CD.

Let me see if I find the code I used to get at that folder, it even could be just another CSIDL.

Another simple option is to start a Windows Explorer and navigate to the Database folder to point the users to the database they then can backup the way they like.

Bye, Olaf.

 

[rlawrence]

O.K. Olaf,

I'm inclined to take you up on two of your suggestions:

1. Ask the user whether the installation is personal use or for all users.

2. I'll provide a way for users to launch Explorer to the location of the database. That should help clarify the location of the data no matter where it is.

Thanks,
Ron