FileMaker's ODBC Driver doesn't release Ha

Question

After a whole day tracking down a memory leak in my VB.NET project, I have traced the cause to a bug with FileMaker's ODBC driver !

To reproduce you'll need a database you can connect to (I have mine hosted on Server Advanced 11.0.3, but you can also host it locally), and the ODBC driver registered/installed on the PC (I tested versions 11.3 and 12.0, and the latest 12.2).

Start a new VB.NET WinForms project, add a button to the form and paste this code onto the button's click event:

Using cn_FM As New Odbc.OdbcConnection("DRIVER={FileMaker ODBC};SERVER=192.168.1.xxx;UID=admin;PWD=admin;DATABASE=test;")
    cn_FM.Open()
End Using

All this code does is open a connection to a FileMaker database, however if you analyse the memory usage in Windows Task Manager you can easily see (by repeatedly clicking the button you just made) that cn_FM is not being disposed properly because the Handles keep increasing! I tried forcing Garbage Collection but this didn't do anything, so I assume its a problem with the driver itself.

Oh, and I tested connecting to a SQL database in the same way, and as you would expect, there was no handle leakage...

Can anyone confirm this is correct?

Edit: I tried various ways of opening and closing the connection, as well as actually querying the database for something in the using block. Also tried hosting the fp7 file locally, but still no go :(

Answer 1

FileMaker's ODBC drivers are horrible and they admit it. You'll also find that your CPU spikes to nearly 100% for every query you hit the FM server with. I've been griping at them about it for years.

Their "solution" was to introduce External SQL Sources, but that requires you to go the other direction. You can bind your VB database to FileMaker and then access the data just like actual FileMaker data. This will allow you to create scripts on the FM server to sync whatever tables you need to sync with your VB database.

It's not ideal, but that's going to be your best bet to get something together with good performance.

Answer 2

I got around this problem by making a persistent connection (declare and open it once and leave it open). But I need to check if its still open each time I want to use it, for example:

Public Sub CheckOpen(ByRef cn As Odbc.OdbcConnection)
    If cn.State <> System.Data.ConnectionState.Open Then
        cn.Close()
        cn.Open()
    End If
End Sub

If you have multiple FM database files then this may mean you need to have one connection for each file.

Side Note: FileMaker's xdbc_listener.exe process running on FMSA is also leaky. We have noticed a pattern that once it reaches just under 2GB memory usage it crashes. So keep in mind that the process may need constant restarting.