You can find the web services add-in for access 2003 here:
http://www.microsoft.com/downloads/...8A-E1CF-48A3-9B35-169D819ECF18&displaylang=en
In many cases, you find it better off to use the msXML library in place of
the soap add-in.
It a lot less code
try:
Public Sub GetQuote2()
Dim objXML As Object
Dim strSymbol As String
Dim strURL As String
Dim strWFormat As String
Set objXML = CreateObject("MSXML2.XMLHTTP")
strURL = "
http://ca.finance.yahoo.com/d/quotes.csv?s="
strWFormat = "&f=sl1d1t1c1ohgv&e=.csv"
strSymbol = "MSFT"
objXML.Open "GET", strURL & strSymbol & strWFormat, False
objXML.Send
Debug.Print "Symbol = " & Split(objXML.ResponseText, ",")(0)
Debug.Print "Trade = " & Split(objXML.ResponseText, ",")(1)
Debug.Print "Date = " & Split(objXML.ResponseText, ",")(2)
End Sub
Output when above run:
Symbol = "MSFT"
Trade = 24.62
Date = "9/4/2009"
The above code example happens to "GET" a CSV file, but in most cases that
web service will give you a xml file or even document. Using the MSXML
library also means you have full xml parsing at your fingertips.
You can/could also write out the xml text string to a local file and use the
XML import features we have in ms-access.
In most cases I think the above is FAR LESS work then the soap web tool kit.
and the main problem with the soap kit is it generates class modules for
each property/method of the xml service. While having inti-sense during
development is nice, adding additional web features or removing them
if the web services side is under development makes things somewhat painful
on the ms-access side to maintain that code base. Often several additional
class modules need be to added for each new method of the web service.
And, changes in the web services can often break the access side of code.
