What is the status of wsdlc.exe?

[Breck_Carter]

The wsdlc.exe utility was documented in the SQL Anywhere 12 Help, and delivered in the bin32 and bin64 folders on Windows, but it is gone from all three locations in SQL Anywhere 16.

By "gone" I mean MORE than just Monty-Python-parrot-dead, there's no body, not even an obituary in the "removed features" section.

There ARE traces remaining, however... fond mentions in some of the sample code of how wsdlc was instrumental in generating SQL-from-URLs; e.g.,

C:\\Users\\Public\\Documents\\SQL Anywhere 16\\Samples\\SQLAnywhere\\HTTP\\soap.globalweather.sql

[VolkerBarth]

Just to add from @Mark's answer to that other question:

FWIW, you can always use wsdlc from a pre-16 installation to generate the web service declaration - it will still work in SA 16.

[Former Member · Accepted solution]

Breck,

This utility was removed in SQL Anywhere 16 for two reasons: (1) It was used for generating code for mobile web services applications with QAnywhere, and QAnywhere was removed, and (2) its existence for generating SQL SOAP client procedures for SQL Anywhere web services was thought to be no longer justified given the decreasing popularity of SOAP.

We meant to remove all mention of it from the documentation but apparently we didn't quite succeed. It would be worth a comment in DCX where you see it mentioned.

[VolkerBarth · Accepted solution]

It would be worth a comment in DCX where you see it mentioned.

I can't comment on the pros and cons of removing the utility itself, however, the according statement in the "removed features" section seems really worthwhile - particularly, as folks rely on these sections (and have confidence in their completeness!). Just my 2 cents:)

[Breck_Carter · Accepted solution]

What is the recommended alternative for SQL SOAP client procedures?

[MarkCulp · Accepted solution]

Not noting the removal of the utility in the "removed features" section was another failure on our part 😞 The utility was removed quite late in the release cycle and obviously the documentation did not catch up (likely because development forgot to tell the doc team to do it - Doh!!)

[MarkCulp · Accepted solution]

IMHO I would say that the recommended alternative would be to use JSON or simple XML. SOAP is such a complicated "standard" - the "standard" is so large and extensive that everyone does it their own (different) way. JSON is a much lighter weight representation and is easily consumed and generated by Javascript (if you happen to be consuming / generating it from a web app running within a browser). Even simple XML is more understandable than SOAP.