XP & Vista & Win 7 My Doc Directory Structure.

[Dennis]

Hi,

I'm developing using Access XP Office on Windows 7. My users are running
Access XP and Access 2007 on Widows XP, Vista, and Windows 7.

I not quite in which forum this question belongs, but since it came up in a
form, I'm asking the question in this forum.

I have "blob" type files (.tiff, .jpg, etc.) that were stored in different
sub-directories under C:\Documents and Settings\<User Name>\My
Documents\....." Rather than store the file in the database, I store the
full path and file name in my database.

As you know MS, "in their infinite wisdom" , decided to change the
"Document" directory structure on Vista and Windows 7 to "C:\Users\<User
Name>\Documents\....".

Fortunately, the first user to when to Vista had not used the "blob" files
very much, but they had a few. So I had to go in by hand and change the path
names. However, it did point out a flaw in how I am storing the path name.

I need to change how I store my path names so I don't have to manually
convert them (or write code to convert them) when other users upgrade to
Vista or Windows 7.

Any suggestions?

Do I have to parce the path name and store it in pieces so that I can
reassemble the correct file name name depending upon which OS I'm on or is
there a better way.

Thanks,


Dennis

 

[Douglas J. Steele]

For what it's worth, it really wasn't appropriate to hardcode "C:\Documents
and Settings\<User Name>\My Documents\....." under XP: for instance, on my
XP machine, my My Documents folder is located on the D drive.

Use the SHGetSpecialFolderLocation API, as outlined in
http://www.mvps.org/access/api/api0054.htm at "The Access Web". The
specific invocation you'll want is fGetSpecialFolderLocation(CSIDL_PERSONAL)

 

[David W. Fenton]

Any suggestions?

Doug Steele has given you the correct approach on how to find the
appropriate folders. Note that some of the defined folder locations
have changed writability by non-admins between WinXP and Vista/Win7
(e.g., \All Users\AppData, previously world writable, now writable
only by admins, so it's no longer a place to put your front end on a
machine shared by multiple users -- instead each user has to have
their own copy, or you have to set permissions manually).

For an explanation of what the AppData folders mean in Vista/Win7,
see this downloadable Word document:

http://tinyurl.com/yccs3c =>
http://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-
9c96482f5353/Managing%20Roaming%20User%20Data%20Deployment%20Guide.do
c

It's intended as an explanation for sysadmins that implement roaming
profiles, but, in fact, parts of the explanation also apply to
non-domain-connected machines, and domain-connected machines without
roaming profiles.

 

[Dennis]

David,

Thanks for the info. I will be reading those articles. More to learn!


Dennis

 

[Dennis]

Douglas,

Your Comment: For what it's worth, it really wasn't appropriate to hardcode
"C:\Documents and Settings\<User Name>\My Documents\....." under XP: for
instance, on my XP machine, my My Documents folder is located on the D drive.

My Response: I see you point and I agree. However, after reading your
response I see where I left out an important piece. I'm still learning for
excuse the faux pas.

I did not "hardcode" my paths. My users create or download their documents
into their directory and then "attach" the documents to their access
database. I use file FileOpen routine that I found on one of the MVP website
(I forget whose). This routine access the standard windows File Open window.
The user navigates to the directory in which their documents is stores and
selects the document. The routine returns a path and a file name which I
then store in my database.

I guess at that point I am going to have to parse the path that is returned
and store it in pieces. This seems to be a pretty "ugly" way to do it. I
was hopping there is a better way to do this.


Dennis

 

[Dennis]

Doug,


Your comment: Note that some of the defined folder locations have changed
writability by non-admins between WinXP and Vista/Win7 (e.g., \All
Users\AppData, previously world writable, now writable only by admins, so
it's no longer a place to put your front end on a machine shared by multiple
users -- instead each user has to have their own copy, or you have to set
permissions manually.

My Response:
Normally I put my front end in my own directory directly of the drive
letter. Is that a bad way to do it? I've done it this way to avoid the
multi-use issue. I guess the only issue then is all users have access to the
app, no just the desired user. But I've only had this issue pop up once.
But your point is well taken.

What is your advice for where to place the front end software?


Dennis

 

[Douglas J. Steele]

I'm confused. The FileOpen dialog (such as what's at
http://www.mvps.org/access/api/api0001.htm at "The Access Web") returns the
full path to the file, so what parsing do you need to do?

Are you trying to split the full path into folder and file? Use the InStrRev
function to find the last slash in the path:

strFullPath = ahtCommonFileOpenSave(...)
If Len(strFullPath) > 0 Then
strFileOnly = Mid(strFullPath, InStrRev(strFullPath, "\") + 1)
strPathOnly = Left(strFullPath, InStrRev(strFullPath, "\"))
End If

 

[Dennis]

Doug,

You are correct, the The FileOpen dialog (at
http://www.mvps.org/access/api/api0001.htm at "The Access Web") returns the
full path to the file.

Returning the full path to the file is the problem! I store the pull path
name in my database and therein lies the problem. This works great until you
upgrade to Vista or Windows 7 and "C:\Documents and Settings\<User Name>\My
Documents\..." no longer exist!


The users started using the software on XP where the full path was
"C:\Documents and Settings\<User Name>\My Documents\....." . The have now
upgraded to Windows 7. Windows 7 moves the data from C:\Doc & Setting\<User
Name>\My Docs..." to "C:\Users\<User Names>\Documents\...". Their existing
data of file paths to documents is no longer valid!

And that is the problem. When upgrading from Xp to Vista or Win 7, I have
to convert the database of file path name. I'm trying to avoid doing having
to convert the data for future users.

Or do I just have to bite the bullent and write a conversion program for
users moving from 2000/Xp to Vista / Win 7?

Thanks,

Dennis

 

[Douglas J. Steele]

So you're storing the full path to the file, and now the file doesn't exist
in that location?

Just store the name of the file and derive the location using the API call.
That should work for both current users and future users.

 

[David W. Fenton]

Doug,

Actually, it was me, not Doug:

Your comment: Note that some of the defined folder locations have
changed writability by non-admins between WinXP and Vista/Win7
(e.g., \All Users\AppData, previously world writable, now writable
only by admins, so it's no longer a place to put your front end on
a machine shared by multiple users -- instead each user has to
have their own copy, or you have to set permissions manually.

My Response:
Normally I put my front end in my own directory directly of the
drive letter. Is that a bad way to do it?

Yes. The root of the system drive is read-only except for
administrators (and possibly other groups, such as Power Users), and
any folders created in it inherit those permissions. You can
manually set permissions to something non-standard, but that
requires human intervention on each individual machine, which means
you can't do it in code (or you have to use an installer program
that can elevate its permissions to do things it can't otherwise
do).

I've done it this way to avoid the
multi-use issue. I guess the only issue then is all users have
access to the app, no just the desired user. But I've only had
this issue pop up once. But your point is well taken.

What is your advice for where to place the front end software?

In the user's profile, one copy for each user of the machine.
There's no disk space issue any longer, so it's a waste of time to
be worrying about multiple copies of the front end on the same
machine, one for each user logon.

 

[Dennis]

Douglas,

Your comments:
So you're storing the full path to the file, and now the file doesn't exist
in that location?

Just store the name of the file and derive the location using the API call.
That should work for both current users and future users.


Response:
First let me apologize for not having all of the information in the first
question. The truth is I had not though about all of the different senarios
that your response is making me think of now.

No, that will not work either. I just found out today that some of the
users are NOT storing their documents in Windows' "My Document" directories.
Some of my users are storing their documents in their own directory structure
completely outside of "My Documents". They are using directory structures
such as C:\Customer\<CustName>\....". The documents that are scanned in goto
"C:\Scan\<scan date>\...". And in stead of the C drive, the data might be on
the network. Using the derived locations will not help in these case.

That is why I figure I will have to parse the path name. If it is the XP or
Vista "MY Doc" structure, then I will have to figure out a way to store that
information. If it is not part of the "MY Doc" structure, then I will have
to store the full path name.

Also, I have to figure out if I want to store the network drive leter (which
I don't think I want to as different computer could have the same drive
letters pointing to different directories, which the should not but who
knows).

Ahhhh, the more I think about it the uglier it gets.

From Access, can I tell if a drive is local or a network drive?
If I can tell, can I get the true name path (DNS path? - sorry don't know
the correct techincal term) - ie. U: really is "\\SBS2003\share"

Again, my apoligize for not having thought this all the way through.
Unless someone else brings up another angle I have not though about, I think
I have provided all of the information you might need. But then again, watch
me be proven wrong.

Thanks for you assitance.

Dennis

 

[Douglas J. Steele]

Take a look at http://www.mvps.org/access/api/api0003.htm at "The Access
Web" for information about determining the details about mapped drives.

 

[Dennis]

David,

My Question: What is your advice for where to place the front end software?

Your Response: In the user's profile, one copy for each user of the
machine. There's no disk space issue any longer, so it's a waste of time to
be worrying about multiple copies of the front end on the same machine, one
for each user logon.


I don't understand this response. If I put one FE in each user's profile,
that I have multiple copies of the code on the machine. I do not want to do
this. I can see putting the code in the Programs directory, but not in each
person's profile.

Since you say there multiple copies are a non-issue, I don't understand your
answer.

I'm missing something, but I don't know what it is. I don't understand how
I can put a FE in each user's profile and not have duplicate copies of the
code.

Could you explain this?

Thanks,

Dennis

 

[Dennis]

Douglas,

Thanks for the link.

Any suggestions on how to deal with storing the different path names between
Xp & Vista / Win 7?


Dennis

 

[Douglas J. Steele]

Is the issue that you've got users who populated the table when they were
running XP and now that they've moved to Visat/Win7, the application doesn't
work? How can you be certain that the necessary files migrated from XP with
the user?

 

[David W. Fenton]

My Question: What is your advice for where to place the front end
software?

Your Response: In the user's profile, one copy for each user of
the machine. There's no disk space issue any longer, so it's a
waste of time to be worrying about multiple copies of the front
end on the same machine, one for each user logon.

I don't understand this response. If I put one FE in each user's
profile, that I have multiple copies of the code on the machine.
I do not want to do this. I can see putting the code in the
Programs directory, but not in each person's profile.

Since you say there multiple copies are a non-issue, I don't
understand your answer.

I'm missing something, but I don't know what it is. I don't
understand how I can put a FE in each user's profile and not have
duplicate copies of the code.

I didn't say you wouldn't have multiple copies. I said multiple
copies are not a problem, and they aren't.

Of course, I assume you have some automated method of pushing out
updates to the front end like Tony Toews's AutoFE Updater
(http://www.autofeupdater.com/). If you are doing it manually, that
can become messy, but you simply shouldn't be doing it manually,
particularly when there are multiple users on each machine (I don't
have many clients with that setup, so I do have some clients with
non-automated front-end updates).

 

[David W. Fenton]

Any suggestions on how to deal with storing the different path
names between Xp & Vista / Win 7?

Don't. Store your front end in the user profile, regardless of where
the user stores other data.

 

[Dennis]

Doug,

Yes, the issue is I have user who populated the table when they were running
XP and now they are on Win7.

The applications still works, it is just that "blob" files are no longer
where they were on XP. When we upgrade to Vista / Win 7, both OSs
automatically restructures the Documents & Settings directories.


Your comment: How can you be certain that the necessary files migrated from
XP with the user?

My Response. I can see the blob files in the new directory.
As I said earlier, on XP the blobl files were in:
C:\Documents and Settigns\<User Name>My Documents\Blob\

When they upgraded to Win 7, Win 7 moved those files to:
C:\Users\<User Name>\Documents\Blob\

The path name in the database is "C:\Documents and Settigns\<User Name>My
Documents\Blob\". If I manually change the path name in the database,
everything works fine.

Any suggestions to avoid this issue in the future. Is there a better way to
store the path names so I can avoid the XP / Vista / Win 7 "Documents &
Settings" vs "User" issue.

Dennis

 

[Paul Shapiro]

One approach I've used is to keep document folders as subfolders of the
application folder. You can get the current application folder with
CurrentProject.Path. Then the only deployment issue is to make sure that
when the application moves, the document folders go with it. For a split
application (Front End/Back End) where users are sharing the data file and
the documents are also shared, I've made the document folder a subfolder of
the backend db location.

 

[Dennis]

Paul,

I like your idea however, I don't have control over where the users place
the documents. Currenly, the bulk of the documents are placed in a scanning
directory by the scanner. I just index in that directory.

I could rewrite the code to move those documents to my own directory.
However, that is only half the problem. The users can attach their Word,
Excel, Notepad, or what every file they want to a customer file. I can not
be moving their files.

Any other suggestions?

Dennis