InfoPath Dev

I'm trying to use the Qdabra Query SharePoint function with the Query Builder. I get an error when trying to connect:

Could not determine the schema.

 Check your connection string and try again.

Details: The query cannot be run for the following DataObject: DescribeListSchema

InfoPath cannot run the specified query.

The SOAP response indicates that an error occurred on the server:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.ApplicationException: Access denied
at Qdabra.Dbxl.QuerySharePointService.CrossDomainAccessCheck(String url)
at.Dbxl.QuerySharePointService.GetListGuids(String listUrl, String& siteUrl, String& webUrl, String&listId, String& webId)
at Dbxl.QuerySharePointService.Qdabra.Dbxl.Services.IQuerySharePointService.DescribeListSchema(Strring listUrl)
--- End of inner excetpion stack trace ---

Originally Qdabra was installed under a separate web app. But I have moved it under the SharePoint web app. 

Hi-

The error seems to suggest that there is some cross domain or cross machine hop.

I believe that DBXL is now installed on SharePoint - 80 and that their app pools are running under the same identity, is that correct?

I guess I would compare the location of the DBXL web service (http://<server>/qdabrawebservice/querysharepoint.asmx) and the location of the SharePoint list (http://<server>/<site>/<listname>). If the portions in bold don't match, I would expect issues to arise.

Currently they are. I enter the same <server> into the Web Service URL prefix and the ShraePoint List URL text boxes. Can you describe to me the authentication workflow if Kerberos is turned on?

It's been about a week. Any new directions?

Just in case someone runs into this same issue, check to make sure that the web.config in the QdabraWebService folder is referencing your SharePoint web application using the same URL defined in your alternate access mappings. It turned out mine wasn't fully qualified when Qdabra was first intalled. It wasn't an option.