views:

41

answers:

2

The question is simple enough. And judging by my last thirty minutes of searching around, I'm assuming that the answer is a resounding "no".

So if it's a no, here's a follow up question: What's the best workaround? Is a COM wrapper around the web service a viable solution for a VBA version that old?

Most of the functionality in the web service is simple data storage and retrieval, which I supposed I could do directly with a database connection. But this would result in a lot of duplicate work, and there are some actual procedural calls in the web service that I would still have to support somehow, perhaps in a standalone executable that gets called from the VBA code.

Does anyone have any thoughts on this admittedly peculiar scenario?

+1  A: 

I would create a wrapper class that was COMVisible around the generated web service proxy class. While I haven't done this for Access 97, I did exactly this to create a client for a web service to be consumed in a classic ASP (JavaScript) application and it worked just fine.

GBegen
A: 

You could try one of the older Office Web Services Toolkits.

The Web Service References Tool is used in the Microsoft Office Visual Basic Editor to create a Visual Basic for Applications (VBA) proxy class module from a selected Web Service Description Language (.wsdl) file. This proxy class can be used to connect and communicate with the web service.

The Office 2003 version of the Toolkit is here. I would try this one first (as it is newer), and use the XP version only if this one doesn't work.

Robert Harvey
Would you expect Access 97 to be compatible with the generated code from those toolkits? I had looked into those toolkits and planned on using them when I thought I was dealing with Access 2003. But once I discovered it was Access 97 I just assumed the toolkit route was not an option.
Jared Thigpen