views:

235

answers:

3

I have used the DIR() command in Microsoft Access 2003 to loop through the files in folder A. This works fine, but I need to check if each file also exists in another location (folder B), and only process the file if it doesn't exist in folder B.

The problem is that checking for the file existing in folder B also uses the DIR() function and this then resets or confuses the original one, with the result that no further files are found in folder A.

Is there a way to check if a file exists without using DIR?

Or, is there a way to have a separate instance of DIR?

I suppose I could build a list of the files in folder A into an array and then process the entries in the array, but this seems rather 'clunky'

Any suggestions for a better solution?

Thanks

A: 

I think the FileSystemObject may be what you're looking for. You would need to set a reference for Microsoft Scripting Runtime (I think that's the name) if you want early binding. I just use late binding to create the object without a reference set.

Dim objFSO As Object
Set objFSO = CreateObject("Scripting.FileSystemObject")

Then if you store the path to folder B in strFolderB and store the file name from Dir() in strFileName, you can do something like this within your main loop.

If Not (objFSO.FileExists(strFolderB & Chr(92) & strFileName)) Then
    'do your processing '
End if
HansUp
A: 

Depending on your operating system(s) and requirements, you may find searching the SystemIndex useful. Here are some notes.

Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim strSQL As String

''This is the Windows Search connection string to use
cn.Open "Provider=Search.CollatorDSO;" _
    & "Extended Properties='Application=Windows';"

''SQL SELECT  statement specifies what properties to return,
''            you can add more if you want
''    FROM -  use SystemIndex for a local query or
''            MACHINENAME.SystemIndex for remote
''    WHERE - specify restrictions including SCOPE and other
''            conditions that must be true

''To add scope restriction:
''strSQL = "SELECT System.ItemName, System.ItemTypeText, " _
''       & "System.Size FROM SystemIndex " _
''       & "WHERE Scope='file:c:\Users\'"

strSQL = "SELECT System.ItemName, System.ItemTypeText, " _
       & "System.Size, System.ItemFolderPathDisplay " _
       & "FROM SystemIndex " _
       & "WHERE System.ItemName='AnExampleFile.mdb'"

rs.Open strSQL, cn
rs.MoveFirst

Do Until rs.EOF
    Debug.Print rs.Fields.Item("System.ItemName")
    Debug.Print rs.Fields.Item("System.ItemTypeText")
    Debug.Print rs.Fields.Item("System.Size")
    Debug.Print rs.Fields.Item("System.ItemFolderPathDisplay")
    Debug.Print String(30, "-")
    rs.MoveNext
Loop

rs.Close
Set rs = Nothing
cn.Close
Set cn = Nothing

Further Information:
http://msdn.microsoft.com/en-us/library/bb266517(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb419046(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb776859(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb231297(v=VS.85).aspx

Remou
There's a major issue with the Windows search solutions, and that's the local vs. remote problem. That is, your local indexing service is not indexing the resources on your file server, and the file server's indexing service isn't indexing the files on your local machine. I don't work in a context where I have an indexing server, so I don't know if one's local index of Windows desktop search can combine the local index with the remote index, but it's an issue that I don't see a solution to. In addition, I've never been able to get it to run on my WinXP workstation (there's a MAPI32 error).
David-W-Fenton
You can search other computers with Scope. I have run searches on XP, but I think it is best on >=Vista, hence the initial comment. The search also returns files from previously connected external drives, which may or may not be a good thing. It is very, very fast on this slow laptop.
Remou
The >= Vista requirement is what I've concluded about it, too, but most of my clients are on WinXP, so I wouldn't consider this solution for any of my clients' apps. None of them have Vista and so far only a handful have Win7. Some day, it will work, but for now, it's impractical, in my opinion.
David-W-Fenton
A: 

I prefer the file APIs as I don't quite trust the FSO. Also see FindFirstFile: Performance Comparison - FSO vs. API With less than say a hundred files the performance difference isn't that significant. Lots of sample code that will be useful for a straight file list or recursively thorugh sub folders at File API Routines

Tony Toews
Having recently run into failure of Dir() on Win7 when searching C:\ and its subfolders, I've been contemplating trying the FSO, since I'd assume it has been updated to handle the changed security settings starting with Vista. My guess is that the API would likewise be updated, but I haven't gotten around to replacing my Dir()-based searches with FSO, so don't know if it solves the security problem.
David-W-Fenton