Which way would be the easiest to learn/implement to provide access for an vb6 legacy application which uses ADO to an SOAP Service. Currently the alternatives I know are ODBC, OLE DB or and ADO provider (is this even something else than OLE DB Provider?). I have basically no knowledge in implementing any kind of this providers. And I am normally programming C#. I have basic C/C++ noledge but it would be great if I could implement the provider in C#.
So my questions:
- Is there any other way to provide the data from the SOAP Service to my vb6 application without modifying it to much. Maybe there exist some kind of ODBC SOAP driver already?
- I looked up some basic infos about how to implement an ODBC driver. As far as i understand the only way is a C/C++ DLL. If I would like to use C# i would have to forward the calls of from the driver dll because C# is not able to export symbols like a native dll; is this correct?
- Both ODBC and OLE DB seam not to have lightweight way to implement the driver/provider. I saw that for OLE DB exists some simplification. I think it is called something like OLS or OSL but the page was stating that the support will end in future versions of windows. Any clue in which or how relevant this could be?
- In which case i should prefer ODBC over OLE DB or vice versa. I know that OLE DB seems to something like the successor of ODBC it seems to be quite complex to implement a provider.
- Does something like an ADO Provider exists? How could i implement this? Or is this just OLE DB?
The obvious answer is upgrade your Visual Basic 6 application but I know that isn’t always practical. If you are after a quick and dirty solution, the fact you are still using VB6 suggests you probably are then you could think laterally.
A quick, dirty BUT easy approach to get the job done would be for you to write a Windows Service or similar in C# that pulls the data from your SOAP source and inserts it into an intermediate database. Then, as far as the Visual Basic application is concerned it is just access the database as it always has done, be via ODBC or any other means.
Not the most elegant solution but a good real-world work around?