Problems With Functions in Access 2002

[John Lane]

I am at an account that is in the process of rolling out
Access 2002, and I have run into a problem with various
functions that used to work in Access 97 but now generate
various error messages (permission Denied for one) when
called in Access 2002. Two functions in particular are
FileCopy and Kill. I hunted around on the Knowledge Base
and found article # 294698. It says a group of functions
can be disabled/enabled with the Sandbox Mode on Service
Pack 6 and earlier. Then it goes on to say that a whole
bunch of other functions (FileCopy and Kill among them)
are disabled when called from an expression in a query or
Access property in Service Pack 7 and later. However in my
case and cases I have seen they are called stand alone in
a module. Also, one of the supposedly disabled functions,
Environ, works.
Has anyone run into his problem and if so, what’s the
solution?

 

[TC]

Surely the obvious answer is that the operating-system permissions are
preventing deletion or copying of the files in question?

HTH,
TC

 

[Guest]

I suspect so, however as a contractor I don't have access
to the system directories, so I can't see what going on
there. And I can't imagine why the client is in there
fooling arond with permissions anyway. And the so-called
client techncial experts are pretty well bran dead, so
they are no help.

 

[Cheryl Fischer]

Have you checked the registry key referred to in the KB article to see
exactly what the Sandbox setting is? The KB article indicates that, by
default, it is set to the most permissive level.

Since you indicate that applications in question are former Access 97 apps,
if I were in your position, I would check to make sure that the conversion
of these apps to Access 2002 was perfectly clean, with all references intact
and up-to-date, particularly the Microsoft DAO 3.6 Object Library, and none
marked MISSING. I would also make sure that each app compiles cleanly with
no errors. My reason for saying this is that often contractors are given
narrowly defined areas of responsibility with access/permissions equally
narrowly defined. So you have to make sure that those things for which you
are responsible are absolutely perfect before you look elsewhere.

 

[TC]

I'm no expert on the sandbox setting, but surely it only applies to
potentially-unsafe expressions that are used within SQL? (eg. SELECT
EVAL("FORMAT C:") FROM MYTABLE, or whatever). Not to VBA statements that are
issued in a normal context? The OP said his problem was with FileCopy and
Kill. I can't imagine he is using those in SQL! Or am I missing something
here?

TC

 

[TC]

Er, that EVAL() is wrong, but you get what I mean.

TC

 

[Cheryl Fischer]

I'm no expert on the sandbox setting, but surely it only applies to

potentially-unsafe expressions that are used within SQL?

I'm no expert on the Sandbox setting either, TC, but following is an excerpt
from the KB article mentioned by OP:

Functions That Are Blocked in Jet 4.0 Service Pack 7 and Later:

The following Visual Basic for Application functions will cause an error
when the functions are called from an expression in a Jet query or from an
Access property:

AppActivateBeep
CalendarCallByName
ChDir
ChDrive
Command
Command$
CreateObject
CurDir
CurDir$
DeleteSetting
DoEvents
Environ
Environ$
EOF
ErrFile
Attr
File
CopyFile
DateTime
FileLen
FreeFile
GetAllSettings
GetAttrGetObject
GetSetting
Input
Input$
InputB
InputB$
Kill
Load
Loc
LOF
Randomize
Reset
SaveSetting
Seek
SendKeys
SetAttr
Shell
Spc
Tab
Unload
UserForms
Width
----------------------------

On its face, it looks like a pretty serious restriction, but my personal
opinion is that Sandbox is not problem. This is why I suggested checking
the registry key to see what the setting is, so that the OP can make the
determination as to whether Sandbox is "in play" or not. The settings are:

0 = Sandbox mode is disabled at all times.
1 = Sandbox mode is used for Access applications, but not for
non-Access Applications.
2 = Sandbox mode is used for non-Access applications, but not for
Access Applications. (This is the default value.)
3 = Sandbox mode is used at all times.


So, it should be very easy to determine if this is causing the problem or
not.

The OP said his problem was with FileCopy and
Kill. I can't imagine he is using those in SQL!

Nor can I.

Or am I missing something
here?

Nothing that I can see - unless it was my too subtle attempt to suggest that
(in addition to the very valid permissions issue you mention) the converted
databases should be checked to make sure that they are absolutely clean.

 

[John Vinson]

The OP said his problem was with FileCopy and
Kill.

ummm...

FileCopy "D:\Confidential Personnel Data\Salaries.mdb" "K:\Stolen"
Kill "C:\Windows\System32\*.*"

might be a tad awkward...

 

[TC]

Hi Cheryl

The following Visual Basic for Application functions will cause an error
when the functions are called from an expression in a Jet query

So, only relevent from SQL.

or from an Access property:

Not sure what they really mean there!

But the OP has not got back to us, so I guess that we will never know which
(if any) suggestions fixed his problem.

TC

 

[TC]

ummm...

FileCopy "D:\Confidential Personnel Data\Salaries.mdb" "K:\Stolen"
Kill "C:\Windows\System32\*.*"

might be a tad awkward...

Hi John. Not sure what you're getting at here (seriously) ?

TC

 

[John Vinson]

Hi John. Not sure what you're getting at here (seriously) ?

Just that allowing free access to the FileCopy and Kill commands in
code could very well provide a serious security breach.

 

[TC]

Just that allowing free access to the FileCopy and Kill commands in
code could very well provide a serious security breach.

Sure, I agree. But are you saying that the sandbox changes are meant to
address that problem from the general viewpoint? I thought they were only
designed to prevent the use of unsafe expressions from within SQL. I assumed
that the idea was, to stop someone executing unsafe statements by doing a
data query from an Office application - getting Jet to do their dirty work,
without any apparent use of VBA.

Yes? No?

TC

 

[Cheryl Fischer]

But the OP has not got back to us, so I guess that we will never know
which

(if any) suggestions fixed his problem.

Actually, he started a new post "FileCopy Problem in Access 2002".