Issues with SOAP Web Service

[jeff2674]

Using Access VBA I am trying to use your SOAP service and having some issues. I can successfully get back information from wms_GetCountryList.

However when I use any other function i'm getting an error. I am a premium members and I know the authentication works since if I change my username or password in my code to a wrong entry it comes back with the appropirate error.

However with the username/password correct, the error comes back as: SoapMapper:Converting data for SoapMapper failed inside the typemapper

Not much luck in googling for an answer. Here is my code, perhaps someone can help?

Also in the struct modules there are two instances where you are using a syntax which is a reserved word. One is 'type' the other is 'in'. Microsoft doesn't allow that. Can that be fixed?

BTW i'm using the MSSOAP30 reference.

Dim clnt As New SoapClient30
Dim objClient As New clsws_RRWsdl
Dim TestInput As struct_authInfo
Dim TestOutput As struct_State

Set TestInput = New struct_authInfo

'appKey, username, password changed for obvious reasons

TestInput.appKey = 12345678  
TestInput.username = "aaaa"
TestInput.password = "bbbb"


txtResults = ""
clnt.ClientProperty("ServerHTTPRequest") = True
clnt.MSSoapInit "http://api.radioreference.com/soap2/?wsdl"

Set TestOutput = objClient.wsm_getStateInfo(30, TestInput) <-- Getting error on this statement
txtResults = Trim(TestOutput.stateName)
MsgBox ("Done")

 

[jeff2674]

Doing a little more debugging I see that it eventually calls the struct_agency. That class module has a line of code:

Public Type As Long

In VB, VBA 'Type' is a reserved word. This is cauing my error. Can you adjust your XML file?

 

[ddb]

reserved word collisions

It's annoying when you run into namespace collisions like that. It's not going to be the only time that this is going to happen to you.

Is there any way to tell the client to map field name "Type" to some other non-reserved word?

While it is possible to change the field name, it is also true that the web service is being used by many languages that have a different set of reserved words. Many SOAP clients understand this and allow you to either map the field names or to fetch values by name.

 

[jeff2674]

Thanks for the reply. That is a good idea, but when I did a search for mapping reserved words I didn't get any sort of answer. I don't think this is possible in VB/VBA.

 

[ddb]

mapping reserved words

If you were looking for a way to "map reserved words," you may overlook the actual solution to the problem.

Is there any way, using your client, to fetch the values of fields without mapping them directly to a data structure?

I know that sounds more complex, but the ability to map the data directly to a data structure is a convenience, not a necessity. I'd look for some method that fetches the value of a field named by a string.

 

[ddb]

In looking at some of the available documentation for SOAP Toolkit 3.0 (which actually looks like it was deprecated back around 2005), it looks like you can directly parse the result yourself.

This means it is possible to do what you need to do, but not necessarily simple or straightforward, but I would say it's worth doing, since it will avoid some common issues down the line.

 

[cpuerror]

Do you have to use Access VBA to do this ?? You can download VB 2008 Express edition for free from Microsoft - http://www.microsoft.com/express/vb/Default.aspx - and use the built in WDSL compiler and SOAP services to make your life much easier. That old SOAP Toolkit was an interim measure and I wouldn't suggest using it unless you really have to.

 

[jeff2674]

I think the VB Express option would be best. It's going to be an addon to my Police Records Management System. It's done in Access, in which 5 PDs are already using. Though I will be porting it over to SQL soon. I'll just create it in VB Express, compile it and then have access call it when they need it.

I appreciate the advice you all have given me. It's frustrating at times when you use a forum to ask a question and never get a response. Thanks again!