sspi

cjbiggs · Post by **cjbiggs** » Fri 09 Sep 2011 13:48

No problem. My manager will email you the information requested. Can I use assembly redirection to use the test assemblies that were email to me to work with my current installed version? Or does it have to be an internal build with the fix? We have the latest dotConnect for PostgresSQL 5.50 installed.

Thanks,

Charlie J.

Shalex · Post by **Shalex** » Fri 09 Sep 2011 16:22

It has to be an internal build with the fix. Looking forward to the e-mail. Please post here when it is sent.

cjbiggs · Post by **cjbiggs** » Fri 09 Sep 2011 17:11

Done. The email has been sent containing the license information requested.

Looking forward to trying out the complete internal build that contains the GSS fix.

Thanks,

Charlie J.

PatrickG · Post by **PatrickG** » Fri 09 Sep 2011 19:15

There seems to be an issue with connection pooling when using SSPI, so you might want to test that scenario. Se my post under "sorry, too many clients already"

Patrick

cjbiggs · Post by **cjbiggs** » Mon 12 Sep 2011 13:23

I have sent our license information this we can obtain the internal build that contains the GSS fix. Please email the internal build to [email protected].

Thanks,

Charlie J.

cjbiggs · Post by **cjbiggs** » Wed 14 Sep 2011 03:11

With the internal build, GSS finally works in our environment. But there are things that stopped working.

1.) Unprepared Execute = true in the connection string doesn't work. When I look at my Postgres logs, all statements are being prepared and performance is real bad.

2.) Max Pool doesnt work. Connections in the Pool are not being reused. A new connection is being created each time exceeding Max Pool.

Thanks,

Charlie J.

cjbiggs · Post by **cjbiggs** » Thu 15 Sep 2011 14:31

With the internal build, GSS finally works in our environment. But there are things that stopped working.

1.) Unprepared Execute = true in the connection string doesn't work. When I look at my Postgres logs, all statements are being prepared and performance is real bad.

[Correction]
The Unprepared Execute = true does work if you also set Devart.Data.PostgreSql.Entity.PgSqlEntityProviderServices.UnpreparedCommandExecution = true; in code. There is an issue with using DBProviderFactory setting this. Please see the following link for more details: http://www.devart.com/forums/viewtopic. ... s&start=45

2.) Max Pool doesnt work. Connections in the Pool are not being reused. A new connection is being created each time exceeding Max Pool.

Thanks,

Charlie J.

Shalex · Post by **Shalex** » Fri 16 Sep 2011 11:50

We are investigating the issue with SSPI/GSS connection pooling.

Shalex · Post by **Shalex** » Thu 29 Sep 2011 14:02

The bug with connection pooling when using SSPI/GSS authentication is fixed. We will post here when the corresponding public build of dotConnect for PostgreSQL is available for download.

cjbiggs, we will send our internal build with the fix to you in two business days.

cjbiggs · Post by **cjbiggs** » Fri 30 Sep 2011 13:39

Thanks Shalex.

Does dotConnect for PostgreSQL 5.50.228 contain the connection pooling fix using SSPI/GSS authentication?

If not, please send the internal build with the fix to [email protected]

Thanks,

Charlie J.

Shalex · Post by **Shalex** » Mon 03 Oct 2011 11:32

cjbiggs wrote:Does dotConnect for PostgreSQL 5.50.228 contain the connection pooling fix using SSPI/GSS authentication?

No, it doesn't. We have sent an e-mail to you with the download link for the internal build with the fix.

We have removed your post in this thread as duplicated.

cjbiggs · Post by **cjbiggs** » Mon 03 Oct 2011 13:32

Thanks. I will do that. Is this built on the top of the latest dotConnect for PostgreSQL 5.50.228? Does it contain the following fix as well? The bug with assigning the UnpreparedExecute option from connection string to the command is fixed

Thanks,

Charlie J.

Shalex · Post by **Shalex** » Tue 04 Oct 2011 08:45

cjbiggs wrote:Does it contain the following fix as well? The bug with assigning the UnpreparedExecute option from connection string to the command is fixed

Yes, it does.

cjbiggs · Post by **cjbiggs** » Tue 04 Oct 2011 13:18

Thanks. The closing of the connections seem to be working. We are verifying that it is actual reusing connections from the pool.

Thanks,

Charlie J.

Shalex · Post by **Shalex** » Mon 24 Oct 2011 16:29

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