The resurrection of a set of old ASP+Access
Due to the various business needs of the company, it is necessary to revive an old ASP+Access information system under the IIS7 environment of a Winserver2008R2 server in the computer room. Considering that the server already has a set of ASP+MSSQL system running normally online, it must be easy to fix, and immediately set up a secondary directory, copy a full set of related files, and configure the relevant directory permissions to run it. The system has been repeatedly and firmly reporting the same error:
Wrong number:-2147467259
Error description: unspecified error
Error source: Microsoft JET Database Engine
The following investigations have been done in turn:
The directory where the ACCESS database of the ASP website is located and the relevant special config directory give users read, write and modify permissions, and even during debugging, the whole site was given complete control by everyone, but failed.
Set the parent path where IIS--ASP is enabled:
Set the program pool that runs the site to enable 32-bit applications:
Permission, or permission question:
Needless to say: the C:\ Windows\ temp directory requires full IIS_IUSRS permission. Another argument is that the temporary directory location of the 32-bit MS Jet engine under IIS7: C:\ Windows\ ServiceProfiles\ NetworkService\ AppData\ Local\ Temp has also been authorized to process.
Later, on an inadvertent click:
Unable to verify access to the local physical path of the web site?
The following settings are made immediately:
At this point, let's try again: ASP+Access can be accessed normally, and the problem is solved perfectly.
Summary: why is it that the previous set of Asp+MSSQL has been working normally, but this set of ASP+Access does not work until the above setting is changed? The official explanation is as follows:
The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify that this built-in account has access. Make sure that the application pool identifies read access with this physical path. If this server is joined to the domain and the application pool identity is NetworkService or LocalSystem, verify that\ $has read access to the physical path, and then retest these settings.
