No i cant reproduce on macos, i can try on w10 pro and w11 pro and windows 2019 server only,
i have uploaded project code on the issue
https://tracker.xojo.com/xojoinc/xojo/-/issues/81390
I tarnished my mbs real license.
You may want to add to your issue:
- Xojo version(s) used
- OS version(s) that you tested
Robin usually asks for that.
1 Like
i have used
xojo rel. 2024r4.2, 2025r3.1, 2026r1.2
os : windows 10 pro, windows 11 pro, windows 2019 server standard edition
1 Like
on the issue, as requested by William, I published the same project without using MBS and using xojo’s mysql plugin and the problem is much more serious: it doesn’t even write 80 records and crashes, the first time reporting an error, the subsequent times no error just the application closing
I’ve run into the same issue using multiple unique instances of a class where each one has its own database connection and thread properties.
My app would crash at random when these classes performed simultaneous queries, and with increased frequency when the number of class instances increased.
I was never able to put together an example project to submit a ticket, but if this was reproducible by the Xojo team and they fix the issue, that would be amazing.
I just wrote off the included plugin as not fully thread-safe and ended up handling it with helper console apps.
Interestingly, I also thought that the MBS plugin would solve the issue, but I saw the same thing there as well.
I’m on macOS, so it definitely affects that platform as well.
Thanks for surfacing this so that it hopefully gets fixed.
1 Like
I’m very busy, but I still think that a redesign of things would help. But the design I think would be a bit complex to write a demo. No timers involved, your several data collectors would be feeding a local SQLite (Wal mode) and maybe 4 fixed data consumer threads (reading sqlite) and also data writers (MySQL). At consumption time a block of records will be selected for update (locked) where status= “ready”, and you will update with “in use” and commit. Every consumer thread only select “ready” status records, and will ignore “in use” or “done”. Also update date/time of the status (important in case o crashes and post mortem analysis like detecting false “in use” from aborted sessions). When you do that another thread will pick another block while you still processing this “in use” block. You will will start writing each of those records in the MYSQL, and when OK mark the status “done” in the source db. At end, this thread sleeps 20ms, and loop.
You will have to deal with much more things, like maintenance, one maintenance thread could be deleting old processed records, doing vacuums and backups late night, etc. Every thread must have its own sets of DB connections, you can’t share them or conflicts will arise.
https://tracker.xojo.com/xojoinc/xojo/-/issues/81390#note_616869
See this comment, 2026r2 Will fix this problem on xojo’s mysql plugin (only)
1 Like
My (real) application code is already like this and works with cooperative threads, the problem is that it fails if I use preemptive threads and this is where the post was born (which I had already published in the past)
I am sorry, but we use exclusively the MySQLCommunityServer plugin—and we do so concurrently across various preemptive threads. Sometimes this involves a single application with multiple connections to one server, and at other times, multiple connections to several different servers. No crashes occur—not a single one. I am quite certain that the issue is not with the plugin per se.
This should be a clear indication that your logic design contains errors or is insecure, and you really should try alternative solutions—not different plugins, but different approaches to overcome the challenges.
Of course, this could also mean that something in the Xojo framework isn’t 100% thread-safe—but that doesn’t help you right now. Sometimes, the only solution is a workaround or a completely new approach…
And we are really just trying to help. 
I noticed in the issue tracker that a bug was indeed found and fixed—that’s great! However, since we implement similar functionality in our own apps and haven’t encountered any such issues, I would still recommend trying alternative approaches.
BTW: In your code example, you use a Try...Catch block for the db.Connect call and a separate one for the query. I think it would suffice to place both the db.Connect and the query within a single Try...Catch block; if db.Connect fails, the program will jump directly to the Catch block anyway. The way you currently have it set up, db.Connect could fail, yet the attempt to execute the query would still be initiated (if you miss to exit the sub) — which would inevitably lead to another DatabaseException.
I suspect that a Try...Catch block always entails a performance overhead; therefore, I would try to use them as efficiently as possible.
And Exit Sub is not necessary at the end of the code, since the program exits the Sub anyway. 
So, instead of:
Try
dbTH.Connect
Catch err As RuntimeException
Exit Sub
End Try
sq="insert into allegati (idAttivitaSecondaria, datainserimento) values( " +Str(Me.ThreadID+i)+", now() ) "
Try
dbTH.ExecuteSQL(sq)
Catch err As RuntimeException
Exit Sub
End Try
i would do a:
Try
dbTH.Connect
sq = "insert into allegati (idAttivitaSecondaria, datainserimento) values( " + Str( Me.ThreadID + i ) + ", now() ) "
dbTH.ExecuteSQL( sq )
Catch err As DatabaseException
// Error Handling
Finally
// Protocoll
End Try
1 Like
ok Sascha, thanks for your suggestions
1 Like
I tried various things here to try to reproduce this.
I changed your example to work with a Postgres server here. No crashes so far.
If anyone has something that produces a few stack traces to see where it crashes, I’d appreciate that.
Otherwise I see I could add some more locking to prevent usage from two commands/queries in one connection.
@William_Yu Does this fix only apply to the API2 ExecuteSQL and SelectSQL methods or does it also fix the API1 calls since it’s internal to the plugin?
Yes, this fixes it also for SQLExecute and SQLSelect.
1 Like
Hi William, I just tried the sample project attached to issue #81390, with Xojo2026r2 version 67545 (because it wasn’t possible to test it in the first 2026r2), and the problem still exists.
Testing it directly in the IDE, the application crashes automatically after inserting about 400 records, likely due to an error, but this error is neither intercepted not displayed by xojo, exactly as it did in xojo2026r1.2.