Error Msg if No C Drive

B

Bob Vance

can I add an error just in case there is no C Drive!

Private Sub cmdInvoices3M_Click()
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"qryInvoiceReport3M", "C:\Temp\Invoices3Months.xls"
End Sub
 
L

Larry Linson

Bob Vance said:
can I add an error just in case there is no C Drive!

Private Sub cmdInvoices3M_Click()
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"qryInvoiceReport3M", "C:\Temp\Invoices3Months.xls"
End Sub

Here is the structure/template I use in most of my VBA procedures:

'---------------------------------------------------------------------------------------
' Procedure : SampleSub
' DateTime : 8/30/2008 17:54
' Author : LARRY LINSON
' Purpose :
'---------------------------------------------------------------------------------------
'

On Error GoTo PROC_Error



PROC_Exit:
Exit Sub

PROC_Error:
MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure
SampleSub of Module MiscAndEtc"
Resume PROC_Exit:

For your information, I have that template set up in a freely downloadable
package called MZTools, available from http://www.mztools.com. You can do
something similar with a (not free) product from FMS, Inc.
http://www.fmsinc.com. Both packages provide other functionality, too. This
is very basic error reporting; error _handling_ would include specific
actions and/or specific messages for particular errors. That, often, is the
result of including something like this to determine the error reported for
a particular condition -- there are so many error reports, numbers, and
description that you'd have to have a photographic memory, and there's no
detailed documentation... although a search in the archives could yield code
to print error code and descriptions. I never found that particularly
productive, because sometimes, just in a list, out-of-context, the
descriptions can sometimes (er, mostly?) be rather cryptic. You better try
code on some other drive letter that you know is not there -- I'm sure I
have never worked on a PC or PC-compatible that did not have a C drive.
<SMILE>

Larry Linson
Microsoft Office Access MVP
 
T

Tom Wickerath

Hi Bob,

As Larry indicates, it would be very rare, indeed, to find a PC that does
not have a C: drive. On the other hand, I would expect that it is more common
to find a system that does not already have a Temp folder created, child to
the root drive (ie. C:\temp). You can trap for this error, and use VBA code
to create the temp folder if it is missing.

Here is code that I use in a startup form of one of my databases, to ensure
that the user is not attempting to run it from a file server. Instead, I want
them to only run it from their local hard drive:

Option Compare Database
Option Explicit

Private Sub Form_Load()
On Error GoTo ProcError

Dim strDriveType As String

' Ensure that the user is running this application from their own local hard
drive
strDriveType = DriveType(Left$(CurrentProject.FullName, 1))

If strDriveType <> "Hard Disk" Then
MsgBox "Please copy this application to a folder on your" & vbCrLf _
& "local hard drive before attempting to run it.", vbCritical, _
"Cannot Run From This Location..."
DoCmd.Quit
End If

' Populate global variable gstrUserName with user's NT Login ID
fOSUserName

' Set Explorer option to the value last selected by user
Me.fraOpenExplorer.Value = Nz(DLookup("blnOpenExplorer", "tblDefault"), 0)

ExitProc:
Exit Sub
ProcError:
MsgBox "Error " & Err.Number & ": " & Err.Description, _
vbCritical, "Error in procedure Form_Load..."
Resume ExitProc

End Sub


The above procedure call the DriveType function, which I have in a
stand-alone module. This function is a slight adaptation from a KB article.
As you can see, it includes a constant for DRIVE_ROOT_NOT_EXIST.

Module Name: basDetermineDriveType

Option Compare Database
Option Explicit

' How To Determine the Type of Drive Using Win32 (Modified version)
' http://support.microsoft.com/?id=161300

Private Declare Function GetDriveType Lib "kernel32" Alias _
"GetDriveTypeA" (ByVal sDrive As String) As Long

Function DriveType(sDrive As String) As String

Dim sDriveName As String
Const DRIVE_TYPE_UNDETERMINED = 0
Const DRIVE_ROOT_NOT_EXIST = 1
Const DRIVE_REMOVABLE = 2
Const DRIVE_FIXED = 3 '<---This is the only type we want to
allow.
Const DRIVE_REMOTE = 4
Const DRIVE_CDROM = 5
Const DRIVE_RAMDISK = 6
sDriveName = GetDriveType(sDrive & ":\")

Select Case sDriveName
Case DRIVE_TYPE_UNDETERMINED
DriveType = "has not been recognized"
Case DRIVE_ROOT_NOT_EXIST
DriveType = "Specified drive doesn't exist"
Case DRIVE_CDROM
DriveType = "CD-ROM drive."
Case DRIVE_FIXED
DriveType = "Hard Disk"
Case DRIVE_RAMDISK
DriveType = "is a RAM disk."
Case DRIVE_REMOTE
DriveType = "Network drive."
Case DRIVE_REMOVABLE
DriveType = "Removable Disk."
End Select

End Function
------------------------------------

Here is an abbreviated form of an error-handler in another procedure, where
I create an output folder if it is not already present. There are several
possible Err.Numbers that I test for, but error 76 is the important one in
this case:

ProcError:
Select Case Err.Number
Case 76 ' Path not found
MkDir CurrentProject.Path & "\" & conOutputFolder2
Resume

Case Else
MsgBox "Error " & Err.Number & ": " & Err.Description, _
vbCritical, "Error in RearrangePFA procedure..."

End Select

Resume ExitProc
End Sub


In my case, the constant "conOutputFolder2" was defined at the beginning of
this procedure as follows:

Const conOutputFolder2 As String = "Processed PFA Files"

In your case, you could define a similar constant as:

Const conOutputFolder As String = "C:\temp"
(after you had first run code to ensure that the C drive was present). If
you defined it as above, then the make directory statement would be modified
as follows:

Select Case Err.Number
Case 76 ' Path not found
MkDir conOutputFolder

I have a download available where you can see all of this in action. It is
available on the Seattle Access web site.
http://www.seattleaccess.org/downloads.htm

Look for the following download:
Compilation of Tools by Tom Wickerath, October 2006 --
Download (656 kb) slides

Note: One of the Word documents in the downloadable zip file, "Find your
data.doc", was simply an announcement that I made at the start of my
presentation regarding the availability of a free article on a normally
subscription-only web service.

Hope this is helpful to you.

Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
A

Arvin Meyer [MVP]

Bob Vance said:
I thought that to Larry but a friend Ive mine said his drive was H

I don't have a C:\ Drive on one of my machines. If one dual (or more) boots,
it is very easy not to have the systemroot on C:\. Also, sloppily written
viruses will look for the C:\ drive instead of the root drive, so one can
slightly increase security.

The %systemroot% drive is how one refers to the drive that has the system
files on it.
 
B

bcap

Why not put the file in the user's own Temp folder?

DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"qryInvoiceReport3M", Environ("userprofile") & "\Temp\Invoices3Months.xls"
 
D

David W. Fenton

Const conOutputFolder As String = "C:\temp"

This is just bloody stupid code.

The root of the C: drive has not be writable for user-level logons
since the release of Windows 2000. The root of C: is absolutely the
wrong place to put any files belonging to a user.

If you're going to create a temp folder, you need to do it somewhere
that is writable. On the other hand, there is no such thing as an
instance of Windows that doesn't have a temp folder already created
for the user logon (it's part of the default user profile creation).
*That* is the right location to put temp files and no other. Ever.

And, again, you should NEVER create folders in the root of C:,
period, end of statement. Recommending such a thing shows that you
are completely out of date in regard to how Windows works, as well
as being someone accustomed to programming for users who are running
in dangerous administrative-level user logons.
 
T

Tom Wickerath

David,
The root of the C: drive has not be writable for user-level logons
since the release of Windows 2000.

Whatever. At my place of work, which is a Fortune 100 Company, I do not have
administrative privileges on my PC. Yet, I can write to the root of the C:
drive without any problem! Yeah, okay, so Mr. David Fenton knows more about
PC security than the folks hired to administer this job at The Boeing
Company. Ya, sure, you-betcha.

I was simply providing an answer to the question that the OP, Bob Vance,
asked. If he wants to use a temp folder off the root drive, then it's not up
to me to come down on him like you have just done to me. I think you can
stick your comments where the light doesn't shine.
On the other hand, there is no such thing as an
instance of Windows that doesn't have a temp folder already created
for the user logon (it's part of the default user profile creation).
*That* is the right location to put temp files and no other. Ever.

You're apparently unaware of the fact that the Vista operating system no
longer allows one to write to this folder programatically, using VBA code
within Access.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
B

Bob Vance

This is what I created seems to be OK! .......Thanks Bob

Private Sub cmdInvoices3M_Click()
On Error GoTo PROC_Error

DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"qryInvoiceReport3M", "C:\temp\Invoices_3_Months.xls"

PROC_Exit:
Exit Sub

PROC_Error:
MsgBox "There Should be a temp File in C Drive, C:\temp "
Resume PROC_Exit:


End Sub
 
T

Tom Wickerath

Hi Bob,
This is what I created seems to be OK!

Yes, except that *any* error that might occur in your procedure will cause a
message box to be displayed that reads "There Should be a temp File in C
Drive, C:\temp". For example, if the query "qryInvoiceReport3M" was later
renamed, but this change was omitted from your code, the message box would
return a misleading prompt to the user. I would use a SELECT Case statement.

Private Sub cmdInvoices3M_Click()
On Error GoTo PROC_Error

DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9,
"qryInvoiceReport3M", "C:\temp\Invoices_3_Months.xls"

PROC_Exit:
Exit Sub

PROC_Error:
Select Case Err.Number
Case 76 ' Path not found
MsgBox "There Should be a temp File in C Drive, C:\temp", _
vbCritical, "Missing Output Folder..."
Case Else
MsgBox "Error " & Err.Number & ": " & Err.Description, _
vbCritical, "Error in cmdInvoices3M_Click Event Procedure..."
End Select
Resume PROC_Exit:

End Sub


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
D

David W. Fenton

Whatever. At my place of work, which is a Fortune 100 Company, I
do not have administrative privileges on my PC. Yet, I can write
to the root of the C: drive without any problem!

That means your company has implemented a group policy to enable
that access.
Yeah, okay, so Mr. David Fenton knows more about
PC security than the folks hired to administer this job at The
Boeing Company. Ya, sure, you-betcha.

If it works at Boeing then it's appropriate for everywhere else?

\/\/hatever.
I was simply providing an answer to the question that the OP, Bob
Vance, asked. If he wants to use a temp folder off the root drive,
then it's not up to me to come down on him like you have just done
to me. I think you can stick your comments where the light doesn't
shine.

You gave bad advice. I corrected it.

Get over it.
You're apparently unaware of the fact that the Vista operating
system no longer allows one to write to this folder
programatically, using VBA code within Access.

No, I have no experience with Vista. Where, exactly, is one supposed
to create user folders in Vista? Is not the user profile fully
writable by the user? If so, how is it that the temp folder is not
writable?
 
D

David W. Fenton

Clarification: And have this temp. folder treated as a trusted
location by Access.

In other words, an entirely different issue than what you suggested.
And, in fact, it sounds like an Access 2007 issue, and not a Vista
issue.

What folders *are* treated as trusted locations by Access 2007?
 
P

Pete D.

I have seen Boeing database software, after many revisions it is almost
usable. Make sure you have a mouse and remember which screen has the
information you need. Might want to keep your checkbook close for the
revisions...
 
T

Tom Wickerath

To be honest, I don't know for sure if it is a Vista issue, or an Access 2007
issue. My only installation of Access 2007 is on a laptop that has Vista
Ultimate as the operating system. I can tell you that it does not work with
that combination. Here is the download, if you care to test it yourself:

TempWorkDB
http://www.accessmvp.com/TWickerath/downloads/tmpwrkdb.zip

If you download this .zip file, you'll notice that I created a new version
that is compatible with Access 2007. This new version creates a temporary
file child to whatever folder the .accdb file is run from. If, on the other
hand, you attempt to run the .mdb version using Access 2007, I think you will
find that it will not work correctly, but, as I said before, I'm not sure if
that is due to Vista or not. I don't have a Windows XP + Access 2007
installation from which to test.
What folders *are* treated as trusted locations by Access 2007?

Only folders that the user specifically trusts. One can also set a registry
key to trust a folder, so an installation program can be configured to do
this for a user automatically, on their behalf.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
T

Tom Wickerath

David,
You gave bad advice. I corrected it.

Answering one's question, without interjecting opinions, is not necessarily
giving bad advice. On the other hand, you really didn't need to act like a
rude snot in your initial reply. You could have offered, in a nicer tone,
that perhaps C:\temp may not be the best place to write temporary files,
because you may find this folder blocked by group policy. There's a nice way
to offer advice, and a not-so-nice way to offer advice. Why is it that you
seem to always gravitate towards the not-so-nice way?
Is not the user profile fully
writable by the user? If so, how is it that the temp folder is not
writable?

See my previous reply, which includes a link to a downloadable .zip file. If
you run the .mdb from Access 2007, it will not work. However, I'm not sure if
it is 2007 that blocks it or Vista that is causing the problem. I simply know
that the combination of Vista plus 2007 cannot be used to write to this
folder.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
D

David W. Fenton

Answering one's question, without interjecting opinions, is not
necessarily giving bad advice. On the other hand, you really
didn't need to act like a rude snot in your initial reply. You
could have offered, in a nicer tone, that perhaps C:\temp may not
be the best place to write temporary files,

You need to get a thicker skin.
because you may find this folder blocked by group policy. There's
a nice way to offer advice, and a not-so-nice way to offer advice.
Why is it that you seem to always gravitate towards the
not-so-nice way?

I am matter-of-fact. I think there's way too much politeness in
these newsgroups. When someone is suggesting something that's
batshit-crazy, I think the response oughtn't be couched in "don't
want to insult you but" terms, but should make clear that the advice
is just flat out WRONG (or, at least, inadvisable).
See my previous reply, which includes a link to a downloadable
.zip file. If you run the .mdb from Access 2007, it will not work.

Yes. You were very, very confused in what you said, as you were
confusing OS security with Access 2007 security.
However, I'm not sure if
it is 2007 that blocks it or Vista that is causing the problem. I
simply know that the combination of Vista plus 2007 cannot be used
to write to this folder.

What folder? The temp folder in the user profile? I find this
difficult to believe.

In any event, if that doesn't work, there are other places in the
user profile that are appropriate (such as application data).
Whether or not A2K7's security won't trust that location is a
different issue, completely orthogonal to the original topic of
discussion, which was about *Windows* security settings.

In that context, C:\Temp is a terrible choice.

And I can't believe for a minute that A2K7 would trust C:\Temp but
not trust <user profile><temp folder>.

Can anyone else who is not emotionally invested in this offer some
actual evidence about this?
 
D

David W. Fenton

To be honest, I don't know for sure if it is a Vista issue, or an
Access 2007 issue. My only installation of Access 2007 is on a
laptop that has Vista Ultimate as the operating system. I can tell
you that it does not work with that combination. Here is the
download, if you care to test it yourself:

TempWorkDB
http://www.accessmvp.com/TWickerath/downloads/tmpwrkdb.zip

I have neither Vista nor A2K7 -- I don't support either at this
point and am steering all my clients away from both.
If you download this .zip file, you'll notice that I created a new
version that is compatible with Access 2007. This new version
creates a temporary file child to whatever folder the .accdb file
is run from.

But I thought the original problem was creating a folder to put the
MDB/ACCDB in when one did not already exist on the local PC's
storage?

[]
Only folders that the user specifically trusts.

Does A2K7 read the user's mind, or is there some method for the user
to tell Access to trust a location? If so, is it accessible via VBA?
One can also set a registry
key to trust a folder, so an installation program can be
configured to do this for a user automatically, on their behalf.

But likely that registry key can't be updated with user-level
permissions, no? It would be a worthless security setting if it
were.
 
P

Pete D.

As a simple Federal Employee I know that no writes to a C: root drive are
allowed unless you are a high system administrator and any contractor that
wants to do that must have approval from the good Computer Gods at the
highest levels. As a matter of fact, access 2007 wizards won't run without
accepting them everytime you start Access. I see standard, expected trusted
locations also being locked down as it doesn't take a rocket scientist to
exploit the weakness. Not taking sides but been there done that and it is
getting tough. If you prevent every vunerablity, users will just find
another way and open new ones.
 
D

David W. Fenton

As a simple Federal Employee I know that no writes to a C: root
drive are allowed unless you are a high system administrator and
any contractor that wants to do that must have approval from the
good Computer Gods at the highest levels. As a matter of fact,
access 2007 wizards won't run without accepting them everytime you
start Access. I see standard, expected trusted locations also
being locked down as it doesn't take a rocket scientist to exploit
the weakness. Not taking sides but been there done that and it is
getting tough. If you prevent every vunerablity, users will just
find another way and open new ones.

Well, that is true.

But if you're designing your Access apps to break the rules of
Windows security on the front end, you really haven't helped that
problem at all.
 
Top