I am using version 12.0.6535.5005 of the msaccess.exe executable on a
Windows 7 64-bit computer. Every time I open and exit Access, the GUI
will be made invisible, but the process is still running in the
background. This occurs even if I do not open any database files--
simply opening msaccess.exe and closing it causes the process to hang.

Has anyone else experienced this issue? Does anyone know if there is
an update to this issue?

Thanks.

Vincent

On Aug 13, 12:47*pm, Vincent <animedrea... (AT) verizon (DOT) net> wrote:
Okay, I may have been seeing things regarding simply opening the
executable. I'm not certain.

I am troubleshooting one particular application and if I do not call a
particular function, the msaccess.exe exits cleanly. If I do call
this function, the msaccess.exe process hangs. The function in
question is shown below and the various API declarations are shown as
well.

Does anyone see an issue with how this is written that would cause
msaccess.exe to hang?

Thanks.

Vincent

Private Function EnumerateDatabases() As Boolean
On Error GoTo Err_EnumerateDatabases

Dim strDBList As String
Dim iSearchHandle As Long
Dim pFindFileBuff As WIN32_FIND_DATA

iSearchHandle = FindFirstFile("v:\*.mdb", pFindFileBuff)

If (iSearchHandle <> INVALID_HANDLE_VALUE) Then
Do
strDBList = strDBList & TrimNull(pFindFileBuff.cFileName)
& ";"
Loop While (FindNextFile(iSearchHandle, pFindFileBuff))
Close FindClose(iSearchHandle)

Me.cmbDB.RowSource = strDBList
EnumerateDatabases = True
End If

Exit_EnumerateDatabases:
Exit Function
Err_EnumerateDatabases:
MsgBox "Error: EnumerateDatabases()" & vbCrLf & Error
Resume Exit_EnumerateDatabases
End Function

Here are the various delcarations:
Private Const INVALID_HANDLE_VALUE = -1

Private Declare Function FindFirstFile Lib "Kernel32" Alias
"FindFirstFileA" _
(ByVal lpFileName As String, lpFindFileData
As WIN32_FIND_DATA) As Long

Private Declare Function FindNextFile Lib "Kernel32" Alias
"FindNextFileA" _
(ByVal hFindFile As Long, lpFindFileData As
WIN32_FIND_DATA) As Long

Private Declare Function lstrlenW Lib "Kernel32" _
(ByVal lpString As Long) As Long

Private Declare Function FindClose Lib "Kernel32" _
(ByVal hFindFile As Long) As Long

Private Type FILETIME
dwLowDateTime As Long
dwHighDateTime As Long
End Type

Private Type WIN32_FIND_DATA
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * 260
cAlternate As String * 14
End Type

I think the problem lies here:

Close FindClose(iSearchHandle)

The Close statement is used to close open files. All you actually need is:

FindClose iSearchHandle

On Fri, 13 Aug 2010 22:40:03 +0100, "Stuart McCall"
<smccall (AT) myunrealbox (DOT) com> wrote:

Good catch. My brain skipped right over that line of code.

Interesting that the code didn't error out.

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

"Tony Toews" <ttoews (AT) telusplanet (DOT) net> wrote

Thanks Tony. If I recall correctly, FindClose returns 1 for success & 0 for
fail. If you issue a Close 1 (with no file open) you don't get an error. Nor
will it error on Close 0, which is meaningless. So the crash was somehow
caused by calling FindClose in this manner. <shrug>

On Tue, 17 Aug 2010 04:22:23 +0100, "Stuart McCall"
<smccall (AT) myunrealbox (DOT) com> wrote:

Actually his code didn't crash but it hung as a background process.

Also when I look at the close statement it doesn't return anything.
Furthermore I just tried it in a module with a non opened file number
and it didn't cause an error of any sort.

So it's the MS VB/VBA folks fault. <smile>

Tony

--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

inline:

"Tony Toews" <ttoews (AT) telusplanet (DOT) net> wrote

You're right, but I (rightly or wrongly) call that a crash.

I was talking about FindClose, not Close.

Exactly my point. So if FindClose was successful it'd return 1, which the
Close statement simply swallows (as mentioned earlier). If FindClose fails
and returns 0, Close is quite ok with that, too.

Agreed. Too much hand-holding. IMO Close ought to fail if there is no open
file using that number. Error 52 would suffice (bad file name or number).