My solution (which also needs to connect to MYSQL web server) is crashing as well using the Actual Drivers- ever since I upgraded to Mac OS 10.6.
I have a feeling that it has something to do the Actual Drivers and Mac OS 10.6 since when I use Windows and the MYSQL open source drivers, everything is fine.
I am currently in an email back and forth with an Actual Technologies rep.-----
Thank you for contacting us. The driver should work fine with Snow
Leopard - I'm not aware of any SL-related reports from our other
Could you tell me the version of MySQL that you are connecting to?
The easiest way to find it out is use the ODBC Manager to select your
DSN and press Configure, then advance to the Conclusion panel. Then,
press the Test button. The driver DSN assistant should display your
MySQL version number.
Actual Technologies - ODBC for Mac OS X
So--- they say there are no compatibility issues.
But from experience, they let us users test and find bugs for them.
I will post anything else I find or hear from them.
I have received this response from Actual Technologies:
We're aware of an issue with MySQL 4.x that causes a crash if there is an "enum" or "set" type. The log file you sent is consistent with this issue. The problem is happening because MySQL 4 is returning the field width for the type information as 40 characters wide, but, for example, the width of
set('yes', 'no', 'flagged to resend', 'not applicable', 'no school found')
is really 74 characters. FMP is setting its internal buffers to be big enough to hold 40 characters, MySQL is sending us 74 characters, FMP overruns the buffer by 34 characters, and then *crash*.
There does not appear to be anything we can do in the driver to fix this, since the bad information is coming from MySQL 4 itself. We're also perplexed as to why this doesn't happen with the Windows versions of the MySQL libraries. This may be one of the reasons why FMP ESS only officially supports MySQL 5 or later.
Does that sound like your scenario? If so, I think you have the following options:
1. Stay with MySQL 4.1 and change the type of the field to be varchar(x), where x is larger than the longest set value (in this case, 17 for 'flagged to resend')
2. Switch to MySQL 5 if you can (installed by default on Leopard Server)<!-- EndFragment -->
Hope This helps.
We do have MySql 4.1.2. I looked at our ODBC logs and see nothing strange there. We also looked in the MySql logs and see no errors. I'll have my developer look for this problem you suggest here with the overrun and get back to you. I truly appreciate your help.
I seem to have the exact same problem
Here's our setup. 11 iMacs running OS 10.5 or 10.6
1 of these is our FMP Server it runs OS 10.6 on a Mac Mini
The other connect via FMP network remotely to this server
We also use the recommended Actual technologies ODBC Driver 2.9c to access our MySql DB on our webserver regularly
We use no other ODBC software or databases on any of these machines
Crashes occur in a number of situations. The same as you stated before
1.For seemingly no reason, just editing a field in FMP it will crash. This is infrequent but does occur.
2. Often, when using the ODBC Driver to access MySQL it crashes. This is the most repeatable, this fails about 50% of the tim
3. Every night the connection from the 'non-server' machines to the FMP server is lost.
I have been speaking to actual technologies about this, the first reply I had was the following - which may help you?
Thank you for reporting this. I would like you to try adding a new keyword pair to your DSN on the FM Server by editing the following file with a text editor:
Locate your DSN and then add the following line below the DATABASE = <database name> line:
ThreadManager = 1
So, it should look something like this:
Driver = /Library/ODBC/Actual Open Source Databases.bundle/Contents/MacOS/atopnsrc.so
Database = test
Server = 192.168.168.200
ThreadManager = 1
You should restart the FM Server after making this change. Please let me know whether it has any effect.
Actual Technologies - ODBC for Mac OS X
Unfortunately this has not stopped the crashing problem for me although Jonathan later stated there will be an update of the ODBC driver with this fix in it.
This is my latest crrespondance to Jonathan:-
"A quick look at the log shows that the driver does not seem to be involved in the crash - it looks like the crash is occurring when FM is preparing to perform an ODBC-related action, but it hasn't yet called the driver. "
So now I am stuck again, still having crashes but now it seems to be a filemaker issue and not the ODBC driver.
Any ideas from anyone
Thank you for the detailed post.
It sounds from Jonathan's message that the crash is occurring with FileMaker Pro.
What was occurring just prior to the crash? Were you running a script? Is it possible the connection to the ODBC driver was lost when FileMaker Pro was trying to access the MySQL database? Do you get crashes when not accessing the MySQL database?
Any other information you can provide may be helpful in narrowing down the possible cause(s).
Thanks for your posting. In reply to your questions.
Prior to the crash:-A message pops up saying find in progress. Which eventually leads to filemaker not responding
The crash can happen when running a script or just updating a field thats part of the mysql databas
Normally the script thats running when it crashes is the following:-
Set field[clients:ref1; global:ref1]
Set field[clients:ref2; global:ref2]
It is possible the connection was lost - how would I see if this was the case? Is there a way of getting filemaker to continuously connect
We do on a rare occassion get a crash when no one is accessing the mysql database. But maybe once this month so not common at all. As oppose to our 4 or 5 times a day currently!
Many thanks for your help if I think of anything else that may help I'll let you know
We've been working offline with scubadiva on this issue. We have released a new version (2.9d) of the Actual Open Source Databases driver that resolves the issue.
The fix is included in the latest Actual ODBC Pack.