MariaDB ODBC – How to Query Excel Using MariaDB ODBC Driver

excelmariadbodbc

I'm using MariaDB ODBC driver version 3.0.2 for Windows(on Windows 10) and can't get excel (Excel 2013) to query the database. I'm able to connect to my MariaDB server using HeidiSQL and query just fine, and my PHP application can query just fine. Now I would like to start pulling data for analytics.

I've setup the DSN using the "ODBC Data Source" tool under Administrative Tools in the control panel. I've just left all of the options blank. Below are some screenshots of how I setup the DSN.

When trying to setup the connection in Excel, I go to the data tab and from the "From Other Sources" drop down, I click Microsoft Query.

Then I select my data source (DSN) from the list and click "OK". Then I get two errors. The first error says "String data, right-truncated" and the second error says "Couldn't read this file". Screenshots below.

I'm not sure what is causing this. I've tried using the servers IP address and the servers resolvable name, and I've tried specifying a database. I've also tried specifying a connection character set and selecting the option for using compression. I've also tried enabling dynamic cursors and the option to return matched rows instead of affected rows. Nothing has made any changes.

UPDATE: This is still an issue for me. 6/21/2018

Best Answer

I've figured out how to execute custom queries against MariaDB in Excel.

Create your DSN using the "ODBC Data Sources (32-bit)" desktop app and leave all options as the default, except the connection page settings and "Return matched rows instead of affected".
In Excel, on the sheet you want the query to show up on, on the data tab, select "From Other Sources" -> "From Data Connection Wizard".
In the dialog that pops up, select "ODBC DSN" and click "Next".
Find the DSN you created earlier and click "Next".
Now you need to select a table, just one. (We will change this later)
Click "Next", then "Finish", then "OK". The data from your table should populate the sheet, starting in what ever cell you specified before hitting that last "OK".

Okay, That's great! But how do I run a custom query with joins and a where clause? Read on my friend.

Select any cell in the table that resulted from the above steps.
In the design tab (should have opened when you clicked into the table) select the "Properties" button.
Click the "Connection Properties" button beside the "Name" field.
Now, on the "Definition" tab, in the "Command text:" field, you can paste in your query.

I've tested this with basic joins and where statements. Everything seemed to work fine, so this should be enough to get you started. I have not tested sub-queries or any other advanced features yet.

Related Solutions

Informatica Source Qualifier not working from Windows ODBC data source (system DSN) from Excel xlsx file

To use an Excel file as a source you need to define a named range containing the cells with data (that's Step 1 of the instruction you referenced in the question).

All the named ranges found in the file will be shown in the Select tables pane. After you select a table (i.e. a range) and click OK, a new source will be created.

You can also consider converting the Excel spreadsheet to the CSV format and using simple flat files as a source. If you're in a Windows environment and have have Excel installed, there's a VBS script that can help you automate this process.

Sql-server – Slow Performance of Parametrized Query in Excel due to Parameter Datatype

The issue appears to be parameter sniffing as the link you provided indicates. I'm not sure how to fix the issue in Excel, but if you can figure out how to specify the datatype when it's creating the parameterized statement, that would fix it.

You have a few options that can help with the issue on the SQL Side. I would only choose one of them and each of them have their price. I think the best solution would be to use a stored procedure to mask it, but you will know your environment the best.

If you can modify the source table:

add a computed column of the NVARCHAR data type, equal to the RunID column, persisted. Increased storage and a minor hit when RunID is inserted or updated but cleanest solution overall. Modify your query from excel to use the computed column.
change the data type of the column to NVARCHAR. This would probably impact everything in your environment, but would be the easiest to implement.
Create a stored procedure that accepts an NVARCHAR as an argument, then cast that to a different variable but with the correct data type, then return the desired results. Clean solution, but requires a stored procedure be created and maintained.

To answer a question below (can't add a comment to my own answer, apparently).

You would create a stored procedure that accepts the NVARCHAR data type as the argument, then explicitly cast that value to a varchar type and use that in the query. It saves the execution plan from doing a conversion on every row. So something like this

CREATE PROCEDURE sptest (@inputparam NVARCHAR(50)) 
AS 
DECLARE @queryparam VARCHAR(50) = CAST(@inputparam AS VARCHAR(50)) 
SELECT * FROM tabletest WHERE columnvalue = @queryparam

Best Answer

Related Solutions

Informatica Source Qualifier not working from Windows ODBC data source (system DSN) from Excel xlsx file

Sql-server – Slow Performance of Parametrized Query in Excel due to Parameter Datatype

Related Question