FileSearch Object not working

[StephenW]

I have a macro which uses a Shell FTP to retrieve a file from UNIX to Windows
to be used as a data source for a mail merge (just acomma deleimited test
file). At one site which is running Windows XP and Word 2002 I'm having
problems with the FileSearch object not finding the file after the successful
Transfer of the file.

First the user was getting a runtime error #70 Permission Denied and after
checking with the site's IT dept. and being assured that the user has Full
rights to the network directories where the action is taking place, the error
continued. I then commented out a KILL command which got rid of the
premissions error (it deletes the script I created to be used in the FTP),
but after that the macro does a file search to be sure that the file is
really there and it always fails, even though I can see the file in the
directory.
The code is:
'***** Delete file with userinformation
Kill (DownloadPath & "Ftpget.txt")

'***** Check if file is present after download
Set objFSO = Application.FileSearch
With objFSO
.LookIn = DownloadPath '***Path to where file is
.FileName = FileToGet '**Name of file
.MatchTextExactly = True
If Not .Execute > 0 Then
'***** File doesn't exists, display error message!
ElseIf FileLen(DownloadPath & FileToGet) < 10 Then
'***** File does infact exists, now check if it is more then 0 bytes =)
error message2
Else
'***** File download succesfull
End If
End With
Set objFSO = Nothing

The user always recieves the first error message. I've check the references
and they are all the same. This code works at other sites. Is there
something that was not installed on this user's machine? Can anybody help?
I'm out of ideas.

Thanks,
Steve

 

[Jonathan West]

Hi stephen

UNIX paths are case-sensitive, and Unix servers return a Permission Denied
error if the path is invalid. Are you sure you have the correct path name
with the correct capitalization?

 

[Jonathan West]

Jonathan,
I'm sure of the path and file name because the file actually gets to the
windows directory. It can be seen and opened "manually", but inside the
macro
the filesearch says it is not there.

Do the contents of the DownloadPath and FileToGet variables have the correct
capitalization of their respective names?

 

[JB]

Jonathan,
I'm sure of the path and file name because the file actually gets to the
windows directory. It can be seen and opened "manually", but inside the macro
the filesearch says it is not there.
Steve

:

Hi Steve,
Why not use a different method of finding the file?
Dir$ maybe or the FSO?

I prefer this:

'Public Function FileExists(sFileName As String) As Boolean
' Dim fs As Object
' Set fs = CreateObject("Scripting.FileSystemObject")
' FileExists = fs.FileExists(sFileName)
' Set fs = Nothing
' Do Messagebox thing here
'End Function

HTH
J

 

[StephenW]

Jonathan,
Yes, I'm sure they have the correct spelling and capitalization. I have this
exact same macro with this coding running on other sites including my own
development machine and I do not have this problem.
Steve

 

[Jonathan West]

Does the Dir() Function indicate that the file exists?

 

[StephenW]

Jonathan,
I can't say I tested that, but the IT Tech. did say that the file could be
seen in the directory, and that the size and Datetime stamp changed during
the testing I was doing. It's not easy for me to get at this stuff, the site
is actually about a 3.5 hour drive away and I do not have any remote
connectivity to the site.

Someone mentioned that this might be a Local Machine User permissions
problem. As I mentioned, the user has Full premissions to the network
directories involved, but I'm told that they are a Limited user on their
local machine. I am unaware of what limitations are put on the user at that
level and I'm not to up on all that local premisssions stuff anyway. What do
you think?
Thanks,
Steve

 

[Jonathan West]

Jonathan,
I can't say I tested that, but the IT Tech. did say that the file could be
seen in the directory, and that the size and Datetime stamp changed during
the testing I was doing. It's not easy for me to get at this stuff, the
site
is actually about a 3.5 hour drive away and I do not have any remote
connectivity to the site.

Someone mentioned that this might be a Local Machine User permissions
problem. As I mentioned, the user has Full premissions to the network
directories involved, but I'm told that they are a Limited user on their
local machine. I am unaware of what limitations are put on the user at
that
level and I'm not to up on all that local premisssions stuff anyway. What
do
you think?

I think you ought to get them to email you a screenshot of Windows Explorer
pointing to the correct folder, so that you can check the actual path for
yourself. There's nothing quite like an old-fashioned inspection with a Mk.
1 eyeball to make sure that things are how you have been told they are.

Word runs under the same permissions as the user running it, so if the user
can see the file in Explorer, then Word *must* be able to see it as well.

I had exactly the same problem myself on a customer site a few months ago.
The user templates folder was mapped to a share on a Unix server. The
Options.DefaultFilePath(wdUserTemplatesFolder) property gave me the folder
path all in lowercase, but the actual path had uppercase characters in it,
and so the search failed with a Permission Denied error.

The workaround I used was to recode using the NormalTemplate.Path property
instead, which points to the same folder, but does maintain proper case.

 

[StephenW]

Thanks I'll look in to what you suggest.
Steve

I think you ought to get them to email you a screenshot of Windows Explorer
pointing to the correct folder, so that you can check the actual path for
yourself. There's nothing quite like an old-fashioned inspection with a Mk.
1 eyeball to make sure that things are how you have been told they are.

Word runs under the same permissions as the user running it, so if the user
can see the file in Explorer, then Word *must* be able to see it as well.

I had exactly the same problem myself on a customer site a few months ago.
The user templates folder was mapped to a share on a Unix server. The
Options.DefaultFilePath(wdUserTemplatesFolder) property gave me the folder
path all in lowercase, but the actual path had uppercase characters in it,
and so the search failed with a Permission Denied error.

The workaround I used was to recode using the NormalTemplate.Path property
instead, which points to the same folder, but does maintain proper case.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup