Data Access Page Error
I am using Windows XP Professional with IIS 5.1 installed to host data access pages for an MS Access database. I have read through endless pages of configuration documentation, but I always end up with this same problem.
When I point Internet Explorer to the data access page on my local web server, it displays the page with empty fields and says "Internet Client Error: Cannot Connect to Server."
I am totally stumpped here.
I have tried several different modifications of c:\winxp\msdfmap.ini that seemed to have no affect at all.
The UseRemoteProvider field has been set to True for all of my test pages. If I try to load the pages from the HD it will properly display an error about that.. but for some reason the page will load from my server and then fail to databind.
Any help or ideas will be greatly appreciated!
When I point Internet Explorer to the data access page on my local web server, it displays the page with empty fields and says "Internet Client Error: Cannot Connect to Server."
I am totally stumpped here.
I have tried several different modifications of c:\winxp\msdfmap.ini that seemed to have no affect at all.
The UseRemoteProvider field has been set to True for all of my test pages. If I try to load the pages from the HD it will properly display an error about that.. but for some reason the page will load from my server and then fail to databind.
Any help or ideas will be greatly appreciated!
ASKER
There are no firewalls on this system. Regardless, I can reproduce this problem at localhost.
Interestingly, if I switch the server from port 8080 to port 80, then the error message changes to "Data provider failed while executing a provider command."
This could provide a few more hours of futile experimentation :)
Interestingly, if I switch the server from port 8080 to port 80, then the error message changes to "Data provider failed while executing a provider command."
This could provide a few more hours of futile experimentation :)
I'm sorry!
Have you tried to post answer also in
Web Development Web Servers IIS
Maybe a IIS problem...
Good luck! ;-)
Roby
Have you tried to post answer also in
Web Development Web Servers IIS
Maybe a IIS problem...
Good luck! ;-)
Roby
ASKER
I have made some progress now. By changing a registry key I am able to connect with the data access page. However, I cannot find any way to make it prompt for the database user name and password. It will connect only if these are stored in the file, and will not prompt for them if they are missing : (
ASKER
Here is a related problem that I would be willing to give points for: When I changed that registry key,
HKEY_LOCAL_MACHINE\Softwar
then the RRAS service failed to load. Changing it back to "system.mdb" has the affect of restoring the RRAS service, but then of course my data access pages will not load properly. Is there any way to get around this? Since that one registry key is the only way I have found to make my access pages databind it is important for this project.
HKEY_LOCAL_MACHINE\Softwar
then the RRAS service failed to load. Changing it back to "system.mdb" has the affect of restoring the RRAS service, but then of course my data access pages will not load properly. Is there any way to get around this? Since that one registry key is the only way I have found to make my access pages databind it is important for this project.
Hi migrogroove!
maybe your Access is not updated with latest patch about Jet?
I've found this link on microsoft:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q239114
HTH (again :) !
Roby
maybe your Access is not updated with latest patch about Jet?
I've found this link on microsoft:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q239114
HTH (again :) !
Roby
ASKER
Thanks for the idea. I am using Windows XP with Service Pack 1 and all of the system updates. Therefore, the patch you mentioned is already installed.
I'm so sorry (sigh! :-< )
I read this on the link I give you:
( http://support.microsoft.com/default.aspx?scid=KB;en-us;q239114 )
"" Click the following link to download and install the correct version of Jet 4.0 SP6 on computers based on the language version of Windows XP that the computer is running.
http://windowsupdate.microsoft.com
On the Windows Update page, click Scan for updates. After the scan is completed, click Windows XP under Pick updates to install in the left pane. The link for the Jet 4.0 SP6 download is listed under Recommended Updates as "Q282010: Microsoft Jet 4.0 Service Pack 6 (Windows XP)" in the right pane. ""
... And I hoped that was the problem...
Roby
I read this on the link I give you:
( http://support.microsoft.com/default.aspx?scid=KB;en-us;q239114 )
"" Click the following link to download and install the correct version of Jet 4.0 SP6 on computers based on the language version of Windows XP that the computer is running.
http://windowsupdate.microsoft.com
On the Windows Update page, click Scan for updates. After the scan is completed, click Windows XP under Pick updates to install in the left pane. The link for the Jet 4.0 SP6 download is listed under Recommended Updates as "Q282010: Microsoft Jet 4.0 Service Pack 6 (Windows XP)" in the right pane. ""
... And I hoped that was the problem...
Roby
ASKER
I have discovered a solution that, while imperfect, seems to allow IIS and RRAS to peacefully coexist.
The important discovery I made is that RRAS will load successfully if the SystemDB key points to an .mdw file that contains the Admin/no password combination.
Therefore, I have created two .mdw files. The necessity for the second file arrises because MS Access will not prompt for a password if the Admin account has no password. If the database is properly configured to deny access to the Admin account, then the .mdw configuration mentioned above would not allow any logins.
The first .mdw file is configured as usual. It has the login user names and passwords, plus the Admin account has a randomized password and is denied all access to the database, and is not the owner of any database objects. The Access Workgroup is set to the location of this file.
The second .mdw file is configured to contain only the login user name and password that will be used by IIS and the data access pages. After this configuration the Admin password is deleted and the SystemDB key set to the location of this file.
It is important to remember that the account common to both .mdw files must have the same key/id string.
This is the best solution I have found so far. If anyone has a solution that does not involve the registry hacks, please let me know.
The important discovery I made is that RRAS will load successfully if the SystemDB key points to an .mdw file that contains the Admin/no password combination.
Therefore, I have created two .mdw files. The necessity for the second file arrises because MS Access will not prompt for a password if the Admin account has no password. If the database is properly configured to deny access to the Admin account, then the .mdw configuration mentioned above would not allow any logins.
The first .mdw file is configured as usual. It has the login user names and passwords, plus the Admin account has a randomized password and is denied all access to the database, and is not the owner of any database objects. The Access Workgroup is set to the location of this file.
The second .mdw file is configured to contain only the login user name and password that will be used by IIS and the data access pages. After this configuration the Admin password is deleted and the SystemDB key set to the location of this file.
It is important to remember that the account common to both .mdw files must have the same key/id string.
This is the best solution I have found so far. If anyone has a solution that does not involve the registry hacks, please let me know.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
Delete question, refund points
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
1William
EE Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
Delete question, refund points
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
1William
EE Cleanup Volunteer
ASKER
Hi 1William. The information I posted on March 10 may be valuable into the future for other Expert Exchange users. Feel free to refund the points but do consider archiving this thread.
Thanks.
Thanks.
ASKER
Regarding my second comment in this thread:
Since I was never able to make the server prompt the user for a database user name and password, I ended up saving them to a file as an unappetizing compromize. But today I came across a fascinating article about this problem at microsoft.com. It does not have a publication date. It only says Last Reviewed 7/28/2004
http://support.microsoft.com/default.aspx?kbid=840258
I will attempt to implement this solution and then post my results!
-- Miqro
Since I was never able to make the server prompt the user for a database user name and password, I ended up saving them to a file as an unappetizing compromize. But today I came across a fascinating article about this problem at microsoft.com. It does not have a publication date. It only says Last Reviewed 7/28/2004
http://support.microsoft.com/default.aspx?kbid=840258
I will attempt to implement this solution and then post my results!
-- Miqro
ASKER
Also, this article points out the problem with the System Database path not being recognized from the Data Access Page Parameters. Appearently, the syntax generated by the Access Page Design View is incorrect:
Jet OLEDB:System database=
The confusion described above involving registry hacks can be avoided by using this corrected syntax:
Extended Properties=Jet OLEDB:System database=
EE Staff please note that it may be necessary to change the accepted solution to this question.
Jet OLEDB:System database=
The confusion described above involving registry hacks can be avoided by using this corrected syntax:
Extended Properties=Jet OLEDB:System database=
EE Staff please note that it may be necessary to change the accepted solution to this question.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
just a thought: maybe your XP firewall blocks connection from your client?
HTH!
Roby