VB6 Problem with http call: XML error

The error number -2146697211 means that the server or proxy server was not found. Make sure the account is enabled, and permissions/rights are in order.

This MIGHT also help, but I doubt it...
http://support.microsoft.com/kb/934387 

Also, this line is suspect...
strEnvelope = "https://www.abc.com..."
Try something like strEnvelope = "https://www.abc.com/index.html" 

Thanks guys, the server addresses and account are fine. The code works perfectly when the program runs within Win XP. It fails when running in Vista as standard user and even when I right click and run as admin.

I read somewhere that Vista doesn't like to switch between unsecure and secure web sites when a certain option is set. You might look into that.

I looked into the Vista secure vs unsecure question and that does not seem to be the problem. I can successfully make the html SOAP call and receive a response using Internet Explorer.  

I also tried making the call with my program to an unsecure address and it failed with the same error.

The only other thing I read about this is to make sure urlmon.dll is properly registered and has its dependencies, and that .NET 3.5 is installed.

.NET 3.5 is necessary for a VB6 app?

I also tried adding shdocvw.dll  to references and it didn't work.

UPDATE: It works if I LOG IN to Windows Vista as an administrator, but not as a standard user even if I right-click and "run as administrator". What's the difference and how can I get this to work for a standard user?

Thanks!

This works for me on a standard account.

Using the following XML for the test.
[example.xml]

<?xml version='1.0'?>
<License>
<data>ABC12345</data>
</License>

Option Explicit

Public Function XMLTest() As String

Dim http          As MSXML2.XMLHTTP
Dim doc           As MSXML2.DOMDocument
Dim mnode         As MSXML2.IXMLDOMNode

Set http = New MSXML2.XMLHTTP
Set doc = New MSXML2.DOMDocument

http.Open "GET", "http://www.somesite.com/example.xml", False
http.send
doc.loadXML http.responseText
Set mnode = doc.selectSingleNode("//data")
If IsNull(mnode) Then
 Debug.Print "No nodes selected"
Else
 MsgBox mnode.Text
End If
Set http = Nothing
Set doc = Nothing

End Function

Private Sub Command1_Click()
  Call XMLTest
End Sub

Select allOpen in new window

Thanks egl...would you please show me how this would fit into/replace my code?

You can replace your code with the example. Update the website address is all you should have to do unless your XML is more complicated than what you shown.

I think the root of the problem is objReturn.Load() where it might expect a file location try using .LoadXML() where you can load a direct string.

Ok, thanks! I'll be able to test this later today. I will update you.  

Ok, thanks! I'll be able to test this later today. I will update you.  

egl, it worked on XP but on Vista, gave the same error (-2146697211), on the http.send command.

hmm.. What reference do you have I used the version: Microsoft XML v2.6

I was using 3.0 but tried 2.6 after you mentioned it. Same result, unfortunately.

I tried sending the string with Internet Explorer and successfully retrieved the server response.

Is it possible for you to provide the real URL or create a temporary URL that I could try on my system? I don't get this error on my system.

egl, are you using Vista?

I tested the code on XP/Windows7 using a standard account. Unless there was some type of hotfix pushed that I don't know about the compatability is identical for Vista/Win7.

Could you change the URL in the code to the test URL that I created and see if it works for you.
http://egl1044.angelfire.com/example.xml

Thanks for hanging in there with this frustrating case, egl!

The URL gives the same error. Clearly there is something going on with my Vista machine but it's not an isolated case. I also received the same complaint about this error with my program from another Vista user.

What could possibly be going on here?

I'm going to write an API version of this just to see if you can get the resulting XML from the site on a standard account.

Will do...thanks!

I can't replicate your problem. The only problem I had was that when I created a new standard account when I manually run internet explorer I had to select my options from the dialogs that prompted for using interner explorer for the first time on a new account. If I never finished this process I couldn't get any connections after choosing the basic options on the dialogs everything was working fine at that point IE must have completed the settings in the registry. This allowed the application to connect without issues on a standard account.

egl, I got suspicious about external factors also and tried logging in as another standard user -- it worked. Then when I went back to the standard user account that was not working -- and it worked!

Somehow, switching to another user account and then back corrected the connection problem. What could cause this? I didn't change any settings. I wonder what I can do to prevent users from encountering this quirky issue?

Even though your original method works, do you think the new one you posted should be used instead? Which one do you think is more robust?

I can't be sure but here was my setup. I had two account types Administrator and Standard Account. I only used the standard account for debug stuff so I probrably never used IE on that account. I am really suspect about the initial settings because it was the first standard account IE might have setup the settings in the registry under they HKEY_CURRENT_USER section. If this was the case then all additional users would inherit these same settings. The first standard user may have never had the settings which IE would need to setup. This is my only suspect cause because I wasn't able to get a connection until I completed the wizard for IE.

The fact that you probrably won't be able to reproduce this problem unless you un-install IE because the per user settings have already been created.

Well you should use the XMLHTTP object to send your requests instead of the API. I wanted to see what the cause of the issue could be and I had to confirm to myself that the API works as intended.

I think sticking with XMLHTTP should be simple enough, the API version is better for downloading files to your hard drive that can be very large > 1MB etc..

Make sure that your data inside the XML is not the real key but an encyption string that your program can convert to a real key. XMLHTTP probrably generates cache copies and anyone can see the key if you use that approach the API gives you more control in the API example you can see that I set specific flags so the file will never be added to the IE cache something to consider.

Last question for you: since the string is being sent to the server of a company that handles our registration keys (and I don't control that end of the communication), I can't use encryption. So it seems the API method is going to be preferable for security reasons.

Are there any drawbacks to the API method that I should be aware of?

Well the example I posted is a direct read of the file which is different than using a GET/POST. If all you needed to do was read the XML file and load to parse XML then there shouldn't be any issues besides that strange problem we both encountered.

If you need to use "GET" then should use HttpOpenRequest(). HttpSendRequest() which is probrably what XMLHTTP does under the hood.

egl1044, you are a fantastic resource! Thanks for all your help.

Please see my other active question if you have a chance.