# Clarion 12 13941 MSSQL Driver Bug **URL:** \ **Category:** questions\ **Tags:** mssql, bugs, c12\ **Created:** [February 12, 2026, 10:16am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940 "2026-02-12T10:16:01Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Justin\_Rumpf](https://clarionhub.com/user_avatar/clarionhub.com/justin_rumpf/32/4805_2.png) [@Justin\_Rumpf](https://clarionhub.com/u/Justin_Rumpf)\ **Post date:** [February 12, 2026, 10:16am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/1 "2026-02-12T10:16:01Z")
I have seen 1 post on this before, from last May 2025 - which didn’t have a strong answer. I am posting this issue again in the hopes it gets addressed. I have also emailed SV for guidance. Long story short, C12 app using the CLAMSS.DLL and ODBC17. When I use the CLAMSS.DLL from C12 - and then run sp\_who2 in SQL, it looks like it opens 1 connection per table maybe? Each DB user has 50+ connections to the database. When I use the C10 version (don’t own C11), then run sp\_who2 in SQL, one connection per DB user - what I am used to seeing. I have employed a few work-arounds like going back to C10 driver. I have also noticed a few deadlock issues in prod where it is creating a transaction around a select statement, never committing it - the transaction goes to suspended in SP\_WHO2, and leaves a deadlock on a table. To remedy this issue for the time being I have set READ\_COMMITTED\_SNAPSHOT to on for this database to prevent the DB from creating transactions on reads. At the core, just swapping this SQL DLL fixes both of my issues. Is this why Capesoft is selling a SQL driver now - because the SV one has issues? or Whats up with this? Any planned fix from SV? Thanks. Justin Rumpf ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [February 12, 2026, 3:58pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/2 "2026-02-12T15:58:14Z")
Did you report this to SV? It needs to be. ---
**Author:** ![vlada\_vukicevic](https://clarionhub.com/user_avatar/clarionhub.com/vlada_vukicevic/32/2343_2.png) [@vlada\_vukicevic](https://clarionhub.com/u/vlada_vukicevic)\ **Post date:** [February 12, 2026, 4:48pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/4 "2026-02-12T16:48:48Z")
All my applications use only mssql. It worked fine until c12. I reported several problems (it works slower, opens more connections and does not execute some sql queries) and I only got a reply that it will be investigated, but nothing from all the replies. If you copy clamss.dll from c11 to c12, everything works normally as before. That’s why I haven’t switched to c12 yet, it’s not reliable, and I also have problems with sql server 2025. I hope that all these problems will be solved as soon as possible, because you can only work with sql, application development without sql is unusable. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [February 13, 2026, 12:39am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/5 "2026-02-13T00:39:46Z")
What version of ODBC 17 are you using? [Downloads for ODBC versions](https://learn.microsoft.com/en-gb/sql/connect/odbc/windows/release-notes-odbc-sql-server-windows?view=sql-server-ver17#previous-releases) ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [February 13, 2026, 4:33am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/6 "2026-02-13T04:33:06Z")
> [@Justin\_Rumpf](#): > > Is this why Capesoft is selling a SQL driver now - because the SV one has issues? no 🙂 - As it happens I did almost all my MSSQL testing in C11, and it’s very stable there. The primary reason was three fold; a) we wanted native drivers for PosgreSQL, Firebird and MySQL. b) the SV MSSQL driver uses cursors. That’s a normal pattern for CRUD apps, but for us, where we have large data sets, it becomes a problem because it consumes significant server resources. Some of our large cutomers do not like this. So the new driver specifically does not make use of Cursors. c) Since forever, the SV drivers have not handled an unexpected connection termination well. It pretty much just causes the program to hang. In desktop apps it is seldom encountered, but in service apps, or web apps (which run 24x7) it’s an issue every few months or so. So we needed a driver with robust connection handling. Once developement started of course, then the suggestions started flowing. So in addition to the above there are lots and lots of new functionality added. SQL servers have grown a lot in the last 25 years, but the driver command set has remained more-or-less static. It is therefore not surprising that the new drivers give you a lot more control, offer more power, and require far fewer drops to prop:sql calls. The new drivers work on a “one connection per thread” basis. So a typical user might have a “few” connections going at a time. By default all the tables on a thread will share a connection (although you can also choose to split them into different connection “groups”, which is handy for some situations.) Transactions are also connection based (not “file” based) which both improves transaction dynamics (no cross-thread issues to worry about) and also allows for multiple different transactions to be active on the same thread - (rare, but useful…) Lastly, compiling the drivers from source allows for easier understanding of what the drivers are doing in a specific situation, which then frees us from the SV release cycle cadence. Issues can be isolated and fixed quite quickly. The new drivers are not cheap (they encompass a lot of work) but ultimately in professional / commercial situations, they save a ot of support time and grief. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [February 13, 2026, 4:34am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/7 "2026-02-13T04:34:52Z")
If you have examples, or PTSS references then please send them to me. Especially regarding SQL Server 2025. I can’t do anythng about the shipping drivers, but I’m always keen to add tests to the new drivers to make sure they don’t have the same problems. ---
**Author:** ![vlada\_vukicevic](https://clarionhub.com/user_avatar/clarionhub.com/vlada_vukicevic/32/2343_2.png) [@vlada\_vukicevic](https://clarionhub.com/u/vlada_vukicevic)\ **Post date:** [February 13, 2026, 12:03pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/8 "2026-02-13T12:03:02Z")
Since I use sql server 2025, mssql tables that have a column of type DATE can no longer be created from the clarion application (errorcode 75). 75 Invalid Field Type Descriptor > Either the type descriptor is corrupt, you have used a name that does not exist in GET(Q,name), or the file definition is not valid for the file driver. For example, trying to define a LONG field in an xBase file without a matching MEMO field ---
**Author:** ![Justin\_Rumpf](https://clarionhub.com/user_avatar/clarionhub.com/justin_rumpf/32/4805_2.png) [@Justin\_Rumpf](https://clarionhub.com/u/Justin_Rumpf)\ **Post date:** [February 14, 2026, 10:24am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/9 "2026-02-14T10:24:15Z")
yes i reported it to them ---
**Author:** ![Justin\_Rumpf](https://clarionhub.com/user_avatar/clarionhub.com/justin_rumpf/32/4805_2.png) [@Justin\_Rumpf](https://clarionhub.com/u/Justin_Rumpf)\ **Post date:** [February 15, 2026, 11:25am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/10 "2026-02-15T11:25:02Z")
The very latest version of ODBC 17 is what I am using. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [February 17, 2026, 3:17am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/11 "2026-02-17T03:17:00Z")
> [@vlada\_vukicevic](#): > > Since I use sql server 2025, mssql tables that have a column of type DATE can no longer be created from the clarion application (errorcode 75). I don’t beleve this is related to SQL 2025, or indeed Clarion 12. I’ve had a problem using CREATE with TIME fields using Clarion 11.1 and MS SQL 2022. ---
**Author:** ![kellyorr](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/eada6e/32.png) [@kellyorr](https://clarionhub.com/u/kellyorr)\ **Post date:** [February 24, 2026, 3:21pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/12 "2026-02-24T15:21:47Z")
We noticed that in C12, it keeps opening more and more process connections when you are browsing a table in SQL. Run sp\_who2 in SSMS and you will see. This is not good behaviour. In C11.1, it only opens 1 process per browse. I reported this to Softvelocity via the Problemtracker website, but they never opened the message. I just tried to go onto the [problemtracker.softvelocity.com](http://problemtracker.softvelocity.com) site and it is down. Essentially, this makes C12 unusable for us. All of our applications use SQL Server and we are afraid we will see it consuming too many resources in SQL causing deadlocks and performance issues. ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [February 24, 2026, 3:30pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/13 "2026-02-24T15:30:41Z")
Kelly, I was able to log into the problem tracker just now. Your ticket is still in “Submitted” status. ☹ ---
**Author:** ![kellyorr](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/eada6e/32.png) [@kellyorr](https://clarionhub.com/u/kellyorr)\ **Post date:** [February 24, 2026, 3:34pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/14 "2026-02-24T15:34:55Z")
It just times out trying to access it: [https://problemtracker.softvelocity.com/](https://problemtracker.softvelocity.com/) I have tried it in Chrome and Edge. ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [February 24, 2026, 4:24pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/15 "2026-02-24T16:24:42Z")
no HTTPS Try: [Problem-Tracker Support System](http://problemtracker.softvelocity.com/CallLogin.php) ---
**Author:** ![kellyorr](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/eada6e/32.png) [@kellyorr](https://clarionhub.com/u/kellyorr)\ **Post date:** [February 24, 2026, 4:27pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/16 "2026-02-24T16:27:47Z")
That works. Too bad they don’t seem bother to open their tickets anymore. In the blog, Bob Z. said there would be a new release last month. Has anyone heard anything about it? ---
**Author:** ![Marino\_Dropulic](https://clarionhub.com/letter_avatar_proxy/v4/letter/m/c5a1d2/32.png) [@Marino\_Dropulic](https://clarionhub.com/u/Marino_Dropulic)\ **Post date:** [February 27, 2026, 11:23am UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/17 "2026-02-27T11:23:07Z")
how to login on that page if you don’t have clarion6 serial? ---
**Author:** ![LANSRAD](https://clarionhub.com/user_avatar/clarionhub.com/lansrad/32/4519_2.png) [@LANSRAD](https://clarionhub.com/u/LANSRAD)\ **Post date:** [February 27, 2026, 1:04pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/18 "2026-02-27T13:04:04Z")
AFAIK, you need to contact SoftVelocity for that. ---
**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\ **Post date:** [March 3, 2026, 9:03pm UTC](https://clarionhub.com/t/clarion-12-13941-mssql-driver-bug/8940/19 "2026-03-03T21:03:42Z")
Just a very wild guess: Is the external name attribute filled with something like `MyFieldID | READONLY`? I was working with an InMemory driver table today and I got the error “Invalid Field Type Descriptor”. So I did a search on ClarionHub. Not found the answer here but then I realised the I copied the fields from another table with the external name attribute filled. Removing that solved my problem. So _ **very maybe** _ this is also an issue for you.