Logon failed. Details: ADO Error Code: 0x Source: Microsoft OLE DB Provider

The error message seems to be saying "VFP OLE DB provider is trying to access Crystal reports file". In such case it should fail.

Or it could mean "The VFP table is not accessible from the report because VFP OLE DB provider settings in the report were not updated for the new server environment".

So, first of all you should place your files to locations being accessible by simple pathes (no special characters, no spaces, names max 8 characters long). Both ODBC drivers and OLE DB providers do not like long names with spaces and other spec. chars.

The error message seems to be saying "VFP OLE DB provider is trying to access Crystal reports file". In such case it should fail.

Or it could mean "The VFP table is not accessible from the report because VFP OLE DB provider settings in the report were not updated for the new server environment".

So, first of all you should place your files to locations being accessible by simple pathes (no special characters, no spaces, names max 8 characters long). Both ODBC drivers and OLE DB providers do not like long names with spaces and other spec. chars.

Hmm, duplicate entry... I supposed it is suppressed at EE. Sorry.

After doing a bit more reading and experimenting I modified the code to this but it still does not work.

mlmcc - The tables are exactly the same.  Since this is only a report I am using the live tables on my development machine to do all the testing.  So yes, the tables are named the same and since these are .dbf files there is no database.

pcelba - Or it could mean "The VFP table is not accessible from the report because VFP OLE DB provider settings in the report were not updated for the new server environment".  

Could you elaborate on this statement?  I'm not sure I know what you mean.  How would they be updated if not with the code below?  Nothing should change?  I had a similer problem access VFP tables from ASP.NET but by using impersonation I was able to overcome.  Some how it appears I need to accomplish the same thing with Crystal.

Dim fname As String = ""
        fname = Request.PhysicalApplicationPath & "clubadmin\Club Backlog Report.rpt"
        Me.CrystalReportSource1.ReportDocument.Load(fname)
 
        Me.CrystalReportViewer1.ParameterFieldInfo.Clear()
        Dim ParamFields As ParameterFields = Me.CrystalReportViewer1.ParameterFieldInfo
        Dim p_SalesRep As New ParameterField
        p_SalesRep.Name = "SalesRep"
        Dim p_SalesRep_Value As New ParameterDiscreteValue
            p_SalesRep_Value.Value = Session("RepCode")
            Dim myConnectionInfo As New ConnectionInfo
            myConnectionInfo.ServerName = "\\sbt-server\sbt\pro50\01"
            myConnectionInfo.UserID = "administrator"
            myConnectionInfo.Password = "112233"
            Dim myTables As Tables =  Me.CrystalReportSource1.ReportDocument.Database.Tables
            Dim myTable As CrystalDecisions.CrystalReports.Engine.Table
            For Each myTable In myTables
                Dim myTableLogonInfo As TableLogOnInfo = myTable.LogOnInfo
                myTableLogonInfo.ConnectionInfo = myConnectionInfo
                myTable.ApplyLogOnInfo(myTableLogonInfo)
            Next
 

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

It seems your FoxPro tables are at "\\sbt-server\sbt\pro50\01". The question is how they are accessible for user executing the report and if Crystal is able to connect these tables by user and password provided. This is not possible to answer remotely without testing. You should try to access DBF tables without logon info first (they have to be accessible by the user which is executing Crystal). The VFP OLE DB provider should allow it. Then you may start with mpersonation if possible.

I cannot help more, sorry.

I copied the tables in question over to a folder on the webserver itself to see if they would be accessible from there and sure enough they were.  There appear to be a problem when ASP.NET has to look at tables that are on another server.  It's certainly a matter of permissions and that's why I had used the code above.  The goal was to provide the appropriate permissions.  So to test I am using the administrator for domain which has permissions to everything but still no good.

Arghhhh......

It could be firewall enabled etc.

Definately not a firewall issue.  I can get at these same files with a connection string using the impersonation.

I can't tell you how frustrating this is.  I now changed back to a mapped drive with the userid now having the domain\username as in domainname\administrator and that changed the error message slightly to.

Failed to open a rowset. Details: ADO Error Code: 0x Source: Microsoft OLE DB Provider for Visual FoxPro Description: File 'somast01.dbf' does not exist. Native Error: Failed to open a rowset. Error in File C:\DOCUME~1\WEBSERV\ASPNET\LOCALS~1\Temp\Club Backlog Report {766F8D06-AF10-45D6-9706-EA6195602797}.rpt: Failed to open a rowset

I really don't know where to turn to next.

I would test the access to data via VFP OLE DB from another program now...

But to help here is really hard.

I am now convinced it's a permissions thing.  The question is how do I overcome it.  I changed the code to read from a path that I created on my local machine C:\pro50\01.  I actually created these folders but didn't copy any data into them.  The error I received was just like the one in my last post.  Basically telling me that SOMAST01.DBF did not exist.  Then I changed the code to look into a folder that didn't exist and I received an error just like the one in my initial post.  This time telling me the path did not exist.

So - I'm guessing that I am now able to see the path but not the files in that path.  Again, the question is why?  The domain\administrator certainly has all the rights but do I need to assign rights to a different user?  And who?

Have you tried providing appropriate access rights to the ASP.NET account from the calling machine on the data hosting machine?

AndrewJen - I'm not sure I know how exactly to do that?  I think I have but you provide some steps so that I can be sure?

Are both computers members of the same domain?

Well yes.  However the webserver is not a domain controller and therefor you cannot assign rights to a mapped drive on another server to the aspnet user of the webservers machine.  Boy, that's a mothful.  You know what I mean right?

I am using impersonation but am unclear if that is used by the Crystal Repots Viewer, but I think not based on these problems.  The impersonation is working in other instances.

I'd try adding access on the data hosting server's folder for \\webserver\aspnet account by right-clicking and going to the security tab. Just a thought...

Actually tried that and it was not allowed.

Since I have the data setup as a linked server, I've now tried creating views for each of the tables and am trying that.  Probably won't work either but its something to try.

Not sure if your security policy would allow this - and not typically encouraged, but have you considered/tried allowing "Full Control" to "Everyone" on that folder?

Definately can't do the full control on those folders.  Would never be allowed.  But I did manage to get the views to work.  The only problem is that it takes over 4 minutes to run a report that should take about 5 seconds.

Yeah, I certainly understand the security policy issues there ;). It would be interesting to 'test' it for an instant to see if this resolved the issue. If it did it would confirm our suspicions re: it being a rights issue.

Did you look at your security log on the file server to see what logon or file access failures took place during the course of the attempted access? It might help narrow down what accounts to grant access to.

No I haven't but that's a great idea.  I'll do that and see what I can find out.

Nothing at all even listed in the logs.  This just keeps getting better...

Do you have that policy enabled on the server - i.e. log file access?

yes

I'm running out of ideas...