I had the following experience while developing an ASP.NET API service to interact with Virtuoso SQL Database Management System
On my local machine, I have a working instance of Virtuoso installed. I compiled a service using VisualStudio which binds it to the ODBC.driver. I am then able to use the service to run SQL queries against the local Virtuoso instance and receive valid responses through the ODBC interface.
I then install the compiled service on Azure which exposes it as a service. Virtuoso is installed on a separate remote machine in a Windows VM. When I make calls to the service to query the remote Virtuoso instance, I get the message: ‘ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.’
An interesting observation was made on a local machine with no Virtuoso instance installed. I compiled the same code for the service using VisualStudio and bind it to the ODBC.driver. Then I used the service to run SQL queries against the remote Virtuoso instance but ended up with the same error message.
Do I need to install some drivers on Azure or what am I missing?
If the ASP.Net service created does not actually bundle the Virtuoso ODBC Driver with itself and register it with the ODBC Driver Manager on the Azure machine, then the Virtuoso ODBC Driver would need to be installed on Azure machine for it to be located, which the error implied it is not.
Hi Williams, please I would like more clarity on this.
Virtuoso is installed on an Azure VM and it is working fine. The ASP.Net service is deployed on an Azure App Service. Azure App Services are PaaS and do not allow installation of anything on them. How would you recommend this is handled?
Or do you mean install the Virtuoso ODBC Driver on the Azure VM that already has a Virtuoso instance running? If that is the case, it already is installed.
How and what exactly can be deployed by/as an ASP.Net service, as I am not an ASP.Net user ?
If you wanted to make an ODBC connection to SQL Server or Oracle for example, how would that be deployed as an ASP.Net service.
As to make an ODBC connection from your application the ODBC driver for the target database must being in place on the machine running the service, so if you cannot installed software on the Azure App PaaS , then it has to be deployed as part of the service somehow would think.
What is your actual use case for Virtuoso and what is the actual data to be queried via ODBC ie is this SQL , RDF or other data ?
I work with @Israel_Bakare and @ademide. The use case is that we are storing and accessing relational data (SQL) on the Virtuoso instance inside an Azure VM. We have a DataService built with ASP.NET, that controls SQL and WebDAV access to the Virtuoso platform. This DataService binds to the ODBC driver at build time. Unfortunately, as has been pointed out, the DataService fails because calls to ODBC fail due to missing ODBC drivers on Azure App PaaS.
The real issue here is, what are the options offered by Virtuoso for remote services to access its SQL and WebDAV functionality apart from the ODBC interface. It should not matter what platform these client services are hosted on.
How do Virtuoso customers access SQL functionality outside of VSP?
As @hwilliams has already indicated, a .NET application doesn’t bundle a driver by default. You have to package the driver (an external component) with your .NET app for the experience you desire. Basically, the tiny “virtodbc.dll” that provides the desired connectivity.
Which is why you also have the following predictable outcome.
An interesting observation was made on a local machine with no Virtuoso instance installed. I compiled the same code for the service using VisualStudio and bind it to the ODBC.driver. Then I used the service to run SQL queries against the remote Virtuoso instance but ended up with the same error message.
Ditto why the ODBC Administrator dialog lists “virtodbc.dll” as the “OpenLink Virtuoso” ODBC Driver file
Also note that you can bundle the Virtuoso ODBC Client Installer for Windows with your application, which takes care of ODBC setup via the ODBC Administrator etc…
