MikeFitz with overflow bit set…

One of my clients had a customer with server somewhere in rural Victoria.  A user (let’s call her Sue) had been running an MS Access 2003 application for years when it suddenly started throwing “Permission Denied” errors.

The Problem

Most of the application worked just fine.  On each form, Sue could navigate through the underlying recordset via the navigation keys; so there was no problem accessing the data.  However, when she tried to select a record via a combobox, she received the “Permission Denied” error.

My client had checked all obvious user login and file access permisssions.  All seemed in order.  He then asked me to have a look at it.

Investigation

My first check was the Access database permisssions. Nothing fancy there.  Any strange record locks? Nope.  Concurrency issues? Nope.

Interestingly, the application worked just fine when logged in as an administrator.  It was only when Sue tried to navigate via the combobox that there was a problem.

Debugging through the code revealed this in the combobox’s AfterUpdate event handler…

Private Sub cboSelect_AfterUpdate()

    ' Find the record that matches the control.
    Dim rs As Object

    Set rs = Me.Recordset.Clone
    rs.FindFirst "[CustomerId] = " & Str(Nz(Me![cboSelect], 0))
    If Not rs.EOF Then Me.Bookmark = rs.Bookmark

End Sub

There must be 60 million copies of this code spread around the planet.  It is generated by the combobox wizard whenever a new combobox is dropped on a form and the developer selects the “Find a record…” option.  There can NOT be anything wrong with this code.  Each of us has done this about a thousand times.

This looks like a job for FileMon !

At this point, we started using FileMon to see which files were being accessed at the time the error occurred.  FileMon monitors and displays file system activity on a system in real-time.

We discovered that the Permission Denied error happened exactly when Access tried to read the DAO360.DLL.   In the code above, rs could be either a DAO or an ADO recordset, depending on which libraries are referenced.  In Sue’s application, DAO was used.

Normally, DAO360.DLL is stored in some common location where it is readable by all users.  Typically, C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL.  However, on this server it was stored in C:\Documents and Settings\Tom\...

The Cause

Now we could see what had happened to “break” Sue’s application.  Tom had recently installed a new Access application which required an upgraded DAO.  Not being a system administrator, he had installed the DAO360.DLL in his own Documents and Settings folder.  Not surprisingly, Sue didn’t have permission to access anything in Tom’s Documents and Settings.

And when we checked with both Tom and Sue, the date of Tom’s installation was around the time Sue first noticed her problem.

The Solution

The solution was to use regsvr32 /u to unregister the DAO360.DLL.  We then moved it to a more accessible location and re-registered it (again, with regsvr32.)

Process Monitor

Note that on recent versions of Windows (Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, Windows Vista), Filemon and Regmon have been replaced by Process Monitor.  This was released in November 2006.

This entry was posted on Thursday, January 11th, 2007 at 1:45 and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.