Unknown connection string parameter ''.

[tommaso.sala]

Hi,

we already own your products (dotConnect for Oracle, SqlServer, PostgreSQL), but we own an old version.

We are now evaluating new versions free trials, to check if our software is fully compatible.

I installed dotConnects products on a VM along with our software.

I'm now having problems with both the paid (Standard) and free version of dotConnect for SqlServer, when connect to specific databases.

Using this connection string sometimes works, sometimes fails with the error in subject:

Server=cla2013;Database=ABB;User Id=ABB;Password=ABB;

Uppercasing and lowercasing "cla" and "ABB", or removing trailing semi-colon, changes the result, without any logic...

Lots of other connection string works just fine.


Any hint on this?


I saw that a similar bug has been fixed in dotConnect for Oracle 8.4.379 on 26-Mar-15:

The bug with throwing the "Unknown connection string parameter" exception in a multithreaded application is fixed

but found nothing about SqlServer's dotConnect.

[Pinturiccio]

Please specify the following:
1. Full call stack of the exception.
2. dotConnect for SQL Server version and edition;

If possible create and send us a small test project with the corresponding DDL/DML scripts for reproducing the issue. Please also describe the steps we should perform for reproducing the issue.

[capt_henry]

I have experienced the same problem yesterday with the latest build of dotConnect for SQL Server. I thought it was something wrong with the connection string but it isn't and was OK in previous builds with the same app. I have been using dotConnect for SQL Server for a number of years without problem.

All OK connecting to SQL Server 2014 with the new build. If I connect to a SQL Server 2008 server it throws the same error and imposes a high CPU load on the server. Not necessarily triggered immediately. But when it is it persists. Changed to system.data.sqlclient and all is ok!

[tommaso.sala]

Server version:
SQL Server 2008 R2

Devart Version:
2.80.1347.0 (both Standard & Professional editions)

Stacktrace:


As you can see, it throws on the Open itself, so there is no DDL/DML to test.

Note that the same code might work or not, in two different applications, using the same ConnectionString provided in the first post.

[Pinturiccio]

Try removing the last semicolon (;) character from your connection string. Your connection string will look like the following after this:

Code: Select all

Server=cla2013;Database=ABB;User Id=ABB;Password=ABB

Does the issue reproduce after this?

Please also specify whether you use multithreading in your application.

[tommaso.sala]

Removing the last semicolon seems to work, but I think this is not an acceptable behavior.

Moreover, it always worked fine with older releases (with trailing semicolon).

It's possible that there are multiple connections form different threads, but I cannot be 100% sure of that.

[Pinturiccio]

You are right, this behavior is incorrect. We are trying to catch the exception in order to fix the issue. We will post here when we get any results.

If you send us a small test project, with which issue can be reproduced, it will speed up finding the reason of the issue and fixing it.

[capt_henry]

Just to provide some helpful feedback.

My app is an ASP.NET web application compiled to a single DLL which connects to a MS SQL Server and MySQL server originally with Devart MySQL and SQL Server providers and developed in VS 2013. It is about three years old, in production at a client and has been updated over the years to the latest component releases. The problem started last Friday (23rd Sept 2015) when I uploaded a release to the production server. Now this was after testing on my dev PC and local server running SQL Server 2014 and MySQL server v5.6.27.

The connection strings in the dev and production builds (in the web.config <connectionStrings> section) are different and have a trailing semicolon. There has been no change in the production or dev connections strings for at least a year.

To keep the production app running I replaced all Devart MS SQL provider references to system.data.sqlclient with no connection string changes. All is OK in production.

Colin

[Shalex]

Please specify the exact target .NET Framework of your project where the error (caused by trailing semicolon) persists.

[tommaso.sala]

We currently experienced the error on a desktop .Net 3.5 application.

[tommaso.sala]

I created a small test project, where I simply open two connections on the same thread:



Here is on my pc, with an older version of dotConnect:




You can download the source here: https://dl.dropboxusercontent.com/u/410 ... Tester.zip

Note that it is compiled on .Net 4.5, but nothing changes.


I don't know what exactly Version refers to, it's always 2.50.518.0...
I printed it from Devart.Data.SqlServer.ProductInfo.Version

Anyway this is what is installed on the failing machine:



and here is what is on my pc, correclty working:




Sql Server is 2008 R2.

[Pinturiccio]

Thank you for the test project. We have reproduced the issue with it. We will investigate it and post here about the results as soon as possible.

[Pinturiccio]

We have fixed the bug with throwing the "Unknown connection string parameter" exception. We will post here when the corresponding build of dotConnect for SQL Server is available for download.

[Pinturiccio]

New build of dotConnect for SQL Server 2.80.1361 is available for download now!
It can be downloaded from http://www.devart.com/dotconnect/sqlser ... nload.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?t=32772

[tommaso.sala]

New build of dotConnect for SQL Server 2.80.1361 is available for download now!
It can be downloaded from http://www.devart.com/dotconnect/sqlser ... nload.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://forums.devart.com/viewtopic.php?t=32772

Good to know! I'll give it a try in the next days.