This sounds like an excel issue, not a filemaker one. Did you make sure to use the correct ODBC drivers?
However, when I am in Excel and begin a new database query Excel crashes every time.
Did you mean when you are in FileMaker? How are you doing the query from within filemaker?
I have a Mac with OS 10.12.2 and Excel 15.30 and I just ran the Microsoft Update to confirm I have the latest version. I have ODBC Manager 1.0.14 from Actual Technologies and I have run the FileMaker ODBC installer from the FMS install in the Extras (FMS installer v 15.0.1). I have created a System DSN for my database on a FileMaker 15.0.2 local server on our LAN (hosted on Mac OS X 10.12.2). I have stepped through the wizard adding the System DSN and at the end I ran the test, put my credentials in, and it says the test ran successfully in ODBC Manager.
I go to Excel and click on the Data tab and "New Database Query" and select "From Database" and it opens the iODBC Data Source Chooser. I see my System DSN and click on it to highlight it and click the Test button and nothing happens.... nothing! I then highlight it again and click the Configure button... it pauses briefly and the unhighlights the chosen datasource and does nothing. Not being sure what to do, I click the "Add" button in iODBC and it pops up a window asking which driver you want to use. I select "FileMaker ODBC" and hit Finish... and it returns to the same screen I had in iODBC manager with nothing... no choice of data source or anything.
I used to do a lot of these ODBC imports into Excel and never had problems. I have the most current FileMaker and Microsoft Products.
I seem to be having the same problem Ross is having. Are others seeing this too?
Oh, FYI, the FileMaker ODBC driver I am using on my Mac is version 14.0.9.
Oh, since it was the last version, I upgraded to the FileMaker 15 driver (15.0.6) and the behavior has changed. Instead of Excel doing nothing, after selecting a data source, it responds with "There was a problem and Microsoft Excel was closed. We apologize for the inconvenience." Oh great... its getting worse now.
FYI, this is what the crash gives the following in the attachment.
ODBC.txt.zip 24.5 K
That is what my set up is doing. I suspect it is an Excel issue but it is so intertwined with the ODBC drivers that I wasn’t sure where to begin.
I cringe thinking about asking Microsoft for help in regards to a FileMaker ODBC driver. I can see the finger pointing before I even call. Of course I don't know it's not the FileMaker ODBC driver even though I suspect it is an Excel problem.
1 of 1 people found this helpful
I have a very similar set up (OS 10.12.5, Excel latest version, ODBC manager 10.0.14 from Actual, FM ODBC driver 13.2.4) and get exactly the same result - the connection tests OK under the ODBC manager, but, won't test, doesn,t cause MSQuery to launch and returns no data when used inside Excel (via Data/Get External Data/From Database, then selecting the connection from the iODBC chooser).
If I use ODBC query software outside of Excel (iQueryODBC for example), it can see and read the data tables in the Filemaker database without problem.
Did you get find a solution?
4 of 4 people found this helpful
The ODBC driver released with FM 16 is compatible with Excel 2016 for Mac:
The driver is unofficially backward compatible with FileMaker 11 and later.
1 of 1 people found this helpful
YES, this finally cracked it, and I can now make ODBC connections from Excel (as client) to Filemker (as data source).
I had tried with v14 and v15 of the ODBC drivers and neither worked but v16 seems to have corrected something. I was 100% convinced that the isse was with Excel!. Many thanks Jonathan
At first glance it seems unusally slow, especially considering that both the database and Excel are on the same local machine. But at least it works!
My set up is:
MacBookPro 15" Touchbar 2016
Excel: 15.34 (via office 365 family subsription)
Filemaker ODBC drivers: 16.0.1
After many months of grief!!!
Thanks for letting us know, actualjon, and testing it out. This sure was frustrating even though workarounds weren't hard. Thanks!