gregarican
IS-IT--Management
Perhaps not technically complicated, really more complex in terms of different components. I have a 64-bit Windows 2008 Server with IIS 7.0 running. This server is going to replace an older 32-bit Windows 2000 Server that's currently in production.
One of the roles the new box will have is hosting up Crystal Reports. These reports were hosted on the old box through its IIS service. I have installed the necessary CR redistributable files on the new 2008 box and most of the SQL-based reports are working fine.
The problem is when I try to test out the Foxpro-based reports on the new box. Previously these reports had an ODBC data source on the old box. Well, from what I've gathered apparently there aren't any 64-bit Foxpro ODBC drivers.
So I recompiled these reports to use the Foxpro OLE DB provider instead. For the data source I point the OLE DB provider to the full UNC path to the Foxpro data directory. This works fine on my development machine. But when I test things out on the 2008 box I get a CR message back stating that the requested page requires logon credentials. That's CR's way to complaining that it can't physically connect to the data set. Because there are no logon credentials. It's just a publically shared directory that everyone has access to.
This might be the wrong forum to post my question in, but it appears as if it's a permissions issues somewhere in tbe belly of the IIS/ASP.NET services. I've set the App Pool to run under a domain admin account as a test. I still get the same results. I've changed it so this UNC path is accessible to the Everyone group (not just the Domain Users group) as another test. Still the same results.
Any suggestions? Our company has a decent amount of Foxpro data on our network and if I can't mine into it using my web-hosted reports this will be a curve ball for sure!
One of the roles the new box will have is hosting up Crystal Reports. These reports were hosted on the old box through its IIS service. I have installed the necessary CR redistributable files on the new 2008 box and most of the SQL-based reports are working fine.
The problem is when I try to test out the Foxpro-based reports on the new box. Previously these reports had an ODBC data source on the old box. Well, from what I've gathered apparently there aren't any 64-bit Foxpro ODBC drivers.
So I recompiled these reports to use the Foxpro OLE DB provider instead. For the data source I point the OLE DB provider to the full UNC path to the Foxpro data directory. This works fine on my development machine. But when I test things out on the 2008 box I get a CR message back stating that the requested page requires logon credentials. That's CR's way to complaining that it can't physically connect to the data set. Because there are no logon credentials. It's just a publically shared directory that everyone has access to.
This might be the wrong forum to post my question in, but it appears as if it's a permissions issues somewhere in tbe belly of the IIS/ASP.NET services. I've set the App Pool to run under a domain admin account as a test. I still get the same results. I've changed it so this UNC path is accessible to the Everyone group (not just the Domain Users group) as another test. Still the same results.
Any suggestions? Our company has a decent amount of Foxpro data on our network and if I can't mine into it using my web-hosted reports this will be a curve ball for sure!
