Clarion 12 13941 MSSQL Driver Bug

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

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

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.

What version of ODBC 17 are you using?

Downloads for ODBC versions

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.

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.

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

yes i reported it to them

1 Like

The very latest version of ODBC 17 is what I am using.

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.

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 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.

Kelly, I was able to log into the problem tracker just now.
Your ticket is still in “Submitted” status. :frowning:

It just times out trying to access it: https://problemtracker.softvelocity.com/

I have tried it in Chrome and Edge.

no HTTPS
Try: Problem-Tracker Support System

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?

how to login on that page if you don’t have clarion6 serial?

AFAIK, you need to contact SoftVelocity for that.

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.