views:

134

answers:

2

I have a native Web service application (ISAPI) that I have built with Delphi 2010. At this time, it only exposes two methods. The first one, EchoString, is designed to give me feedback that the Web service is functioning properly, and it adds a couple characters to the string that I send to it from my Delphi Web service client. This always works fine.

The second exposed method is the one that I am really interested in. I pass this method a string that contains the XML contents of a ClientDataset. From the server side, my code takes this XML and inserts it into a ClientDataset, after which it posts this data to a server-side database.

I am using IBExpress components (IBDatabase, IBTransaction, IBQuery, etc.) to connect to an InterBase database on the server side.

The problem is that as soon as I attempt to connect the IBDatabase component to its database, the Web method fails. I think I have ruled out all other sources for this error. I can create and populate the ClientDataset with a rather large ClientDataSet's XML sent from the client that includes nested datasets with no problems (I am using the MidasLib unit, so the ClientDataSet is not trying to load a DLL). I can create and configure, short of connecting to, the IBDatabase and its various components. Again, with no problems. As soon as I set the IBDatabase component's Connected property to True from within the Web service, it fails.

I am running IIS 7.5 under Windows 7 64-bit Ultimate (on my development machine). I have tried granting full control rights to Everyone (as well as specifically to IIS_IUSRS) to both the specific ISAPI DLL, as well as to the entire directory in which the Web service resides. This did not solve the problem.

I suspect that this is entirely a privileges issue with IIS 7. What can I do to permit my ISAPI Web service to connect to the InterBase client API so that I can use the Web service to write to my database server? ' ' ' ' ' ' ' ' ' ' '
Post Script: It appears that connecting to Interbase from the Web service is not the problem. I am still tracking down the precise cause, but I have now been able to successfully connect to Interbase from within the Web service. I'll update this post once I know the cause, but this question is no longer valid. ' ' ' ' ' '
I am marking Bob's answer as the correct one. The connection string was wrong. Actually (and this is embarrasing, but I'd rather be embarrassed than misleading), I got bit by a with clause.

I stored my connection information in resource strings. I made the assignment in a with clause. The name of the resource string for the DatabaseName property was DatabaseName. The with clause caused the DatabaseName property to be assigned to itself, instead of the value in the resource string. I fixed the problem by prefacing the DatabaseName resource string with the unit name (ie, DatabaseName := IBModUnit.DatabaseName;).

+1  A: 

I assume you can use the same connection string to connect to the InterBase database from a "native" VCL Forms application on that machine?

A silly question perhaps, but do you run InterBase as a service? (Otherwise, the ISAPI DLL will not be able to "see" it to connect to it).

Bob Swart
Yes, on the local machine, the same one on which I tested the Web service, a native client application can use the IBDatabase to connect to the service.
Cary Jensen
But does interBase run as a service on this machine?
Bob Swart
Yes. InterBase is running as a Windows service. I start and stop Interbase using the Services applet in Administrative Tools. It is also true that this service is running on the same machine in which the Web service is installed, but I don't think that changes anything.
Cary Jensen
Bob, you were correct. The connection information was wrong. See the end of my question for a more detailed description of the problem that I caused myself.
Cary Jensen
A: 

[Edit]
Sorry. I wrote a stupid thing suggesting that IIS won't have network permissions <duh!> and I can't seem to delete this post!

But - I did read somewhere that the service permissions on later Windows versions have been reduced somewhat and the localsystem account no longer has network access. Seeing as the post title contains "remote" maybe you need to grant extra permissions to your DLL or service and/or the Interbase service or one of the other files involved?

shunty
Yes, I did use the word remote, in that the version of Interbase I am using is a remote database server. In the particular testing environment, it is an out-of-process server running on the same machine (as a Windows service), but that should not have an effect on what I am seeing. The Interbase API takes responsibility for directing my requests to a remote server, if the database is on a different machine. I can't even talk to the API, apparently.
Cary Jensen
Ok. Another, possibly, silly question. Is fbclient.dll (or the other one gds??? something or other) visible to the IIS service? Maybe it needs to be in the same directory as the isapi dll - that way, at least, we know it can be executed. The main reasons I had for a failure to open the connection was either no fbclient or incorrect (or missing) alias definition.
shunty
Good suggestion. I will look into that this evening.
Cary Jensen
Well, I copied the client API files to the executable directory, but that made no difference. I later discovered that a stupid mistake I made caused the original problem. See my edit at the end of the question to see the solution.
Cary Jensen
Oops. At least you can add that to "the perils of 'with'.." anecdotes :-)
shunty