Joe said:
I've done some limited research into consuming web services in Access
2007. There seems to be one school of thought that prefers using VBA-
code (perhaps created by the Web Services Toolkit on an XP machine but
not on Vista). The other school prefers developing a managed add-in
in .NET.
It seems as if VBA would be the simpler route in terms of time, but
are there advantages to the managed add-in?
I believe one of the PDC demos had Access 2007 consuming web services.
I don't happen to remember which technique was used in the demo. My
current C# instructor, Marc Temkin, pointed out that besides being able
to extend VBA and to create SQL Server User Defined Functions (UDF's)
via assemblies, .NET would allow many calls to API functions in VBA to
be replaced by less OS dependent .NET functions. Yesterday I had to
investigate a situation where the API function used to get the user
information in VBA returned unexpected results when used in Access 2007
on Vista. It returned the user's name rather than the user's login
name. As a temporary workaround, I simply put their name instead of
their login name in the table. Using the .NET Framework functions might
eliminate that problem. Access 2007 was running the mdb in native A2K
format. Regardless of which technique you use to consume web services,
employing the .NET Framework seems to hold a lot of promise for
extending the capabilities of Access so it's going to pay to get
familiar with that technique.
James A. Fortune
(e-mail address removed)
And did you know that all the CLR assemblies must be STATIC? So knowing
STATIC methods and the attributes needed to decorate the methods are
essential. -- Marc Temkin
