Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

This is really more of a windows security question, but here goes. I have a CGI that logs into an Access database on a Windows XP machine. Whenever I have my own processes running, the CGI process (as user IUSR) cannot log in -- I get an error message below. I have tried playing with many security settings, such as the user/password combination on the DBI->connect line, the directory permission, the IIS settings, group membership of the IUSR account, etc. I still cannot get it to log in. Anyone know more about this?
Unable to connect: [Microsoft][ODBC Microsoft Access Driver]General er +ror Unable to open registry key 'Temporary (volatile) Jet DSN for pro +cess 0x10a8 Thread 0xa30 DBC 0x17b2e3c Jet'. (SQL-HY000) [Microsoft][ +ODBC Microsoft Access Driver]General error Unable to open registry ke +y 'Temporary (volatile) Jet DSN for process 0x10a8 Thread 0xa30 DBC 0 +x17b2e3c Jet'. (SQL-HY000) [Microsoft][ODBC Microsoft Access Driver] +Could not use '(unknown)'; file already in use. (SQL-HY000)(DBD: db_l +ogin/SQLConnect err=-1)

Replies are listed 'Best First'.
Re: DBI Access windows question
by iburrell (Chaplain) on May 14, 2004 at 18:33 UTC
    Microsoft Access only allows one process to have the database file open. This is done for safety since Jet (the database engine) can corrupt databases when accessed they are written simultaneously by different processes.

    One solution is to work with copies of the database. Copy the database file, modify with your own processes, and copy it back to the main file.

    The proper solution is to ditch Jet database engine. You can use SQL Server (or MSDE) with Access. This will give you much more reliability.

      ok, thanks, I've made a "user" copy. I was able to have multiple access on another windows machine, and don't recall installing SQL server. Does MSDE come with the system?
        Last I checked MSDE was standard with Office 2000 Professional and above. But be very careful of the licensing requirements, as they are arcane and bizarre. Frankly, if it were me I'd use MySQL over ODBC, but that's just me.