Hi all,
I'm trying to input data from Fabric. We've set up an ODBC connection which seems to be working, and allows us to see and select the tables in our Fabric environment.
However when we run the workflow to actually pull this data, we get this error message --
"Error: Input Data (1): Error SQLDriverConnect:"
There's no further details on that error - not clear what the specific issue is. Has anyone successfully input data from Fabric? Or seen that SQLDriverConnect error with no further detail?
Things we've tried...
- installed Microsoft ODBC Driver 18 for SQL Server
- created ODBC connection on both User and System
Are you getting the error in Desktop or on Server/Gallery?
with my experience.. try and check your access to the server - your access to the DB.. hope this helps!
@Ali_288-1
Were you able to figure this error out? The exact situation is happening on our setup. We're using Service Principal authentication, but get the same error. It lets us see the table in the Visual Table Builder, but running the query or even viewing Stored Procedures it shows that error without any details to go with it. Just curious if you found a solution/workaround?
Sadly no - we're going to have to push our Fabric content out to a SQL warehouse if we want to use it with Alteryx for the time being. I'm sure it'll change in time but currently it's an unsupported datasource, so Alteryx can't find a solution.
Hi there, we are having the same issue with this. Any chance it has been solved?
We've managed to connect with a python script but it doesn't work with the native connector.
Thanks
We use some unsupported drivers in Alteryx. All we had to do was map them to let Alteryx know they were available. Much of what Alteryx maps in terms of viable drivers are Simba drivers. We just went in and made sure that the LUA driver mapping was complete
C:\Program Files\Alteryx\bin\RuntimeData\ODBC
- Look for your file for your driver .lua
- Look for the LUADriverMap.Json This is the place that maps the entry for your driver to the file to use for the handling of it and it maps the .DLL that should run for that driver.
It is easier to open it up and look to see the pattern than it is to explain it. It took me a while, but we have a few non-supported drivers running for various reasons. Much of the information you need can be grabbed by looking at the driver details in the ODBC administrator.
Keep in mind that in-db settings require another entry to be made in the in-db folder in the same path.
-