Clarion 12 13941 MSSQL Driver Bug

1

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

2

Did you report this to SV? It needs to be.

4

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.

5

What version of ODBC 17 are you using?

Downloads for ODBC versions

6

no :slight_smile: - 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.

7

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.

8

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

1 Like
9

yes i reported it to them