Issues in VB6 after move from W2003 to 2008

[DaveHarbud]

About a year ago we moved a number of applications from W2003 to 2008. There are a particular group of errors when connecting to SOAP services. Unfortunately the errors are not well trapped, but we have trapped the error code 0x800A151E. The thing is that these applications have been working since the move and are working on most machines, but over the months on specific machines have stopped. More cases continue to appear. We have tried reregistering the VB routines concerned and reinstalled the software. In one case we have even replaced the PC. We have pasted the addresses of WSDLs concerned into the browser to confirm that the services are available. We are confused by this problem apparently from nowhere and only for specific machines. In at least one case, the user is actually connecting by Citrix and we can't understand why he gets the problems and the other Citrix users don't (and, yes, we have rebuilt the profile). It is not user specific - they can use other machines.
We're quite mystified by this. Our latest experiment is reinstalling SOAP Toolkit 2 - I'm still waiting for the results of that.

[Schmidt]

...Our latest experiment is reinstalling SOAP Toolkit 2 - I'm still waiting for the results of that.

Would guess, that there's a good chance, that the SOAP-2-Update will fix it -
otherwise you could do your SOAP-Requests also "by hand" (it's finally only XML
which wraps your Parameters for the SOAP-RPC, sent by a normal http-request,
results then delivered also as XML) - when you look at the text-format of your
current SOAP-Requests per WireShark - or using a small "go-between-proxy"
which prints out these http-requests content, then you will get a good enough
picture of the XML you will have to provide over normal http-requests.


If you don't have "a ton" of differing and complex SOAP-Request, then coming up
with a small wrapper-class - (which internally makes use of the "Win http Request 5.1"
COMponent - and/or the MS-XML-COMponent) - shouldn't be all that hard IMO.

The thing would get even a bit easier in case the serverside implements a REST-Service,
which is alternatively also capable to serve JSON-requests (delivering JSON-content).

Most "big Webservices" (Google & Co.) offer at least these two versions (XML- and JSON- APIs).

... just another thought - in case your current requests are done over https - then
there's correctly registered certificates needed (at the serverside - and sometimes
also at the clientside, when it was a "cheap, self-generated certificate".

Maybe that's the reason it works on some machines (those who have this certificate) -
and not on some others (that mechanism can work independent of the user-credentials).

Olaf

[DaveHarbud]

Thanks, Olaf

There's some food for thought there

David

[dilettante]

Without knowing more details of your failures a more tactical suggestion is difficult, though I have seen this error reported by some people:

Connector:Connection failed or server refused connection (request might
exceed MaxPostSize). HRESULT=0x800A151E - Client:An unanticipated error
occurred during the processing of this request. HRESULT=0x800A151E -
Client:Sending the Soap message failed or no recognizable response was
received HRESULT=0x800A151E - Client:Unspecified client error.
HRESULT=0x800A151E (n.5406)

Sending the Soap message failed or no recognizable response was received HRESULT=0x800A151E

151E means the HTTP connection failed for the Soap Client when it tried to
connect to the server to send the Soap Message. The things I have seen
cause this are a bad URL in the WSDL file or a URL that is set up to go to
the wrong port because I was running the trace utility and forgot to change
the URL back when I was done. I'm sure there are many other possibilities
but you should probably concentrate on the HTTP connection.