Multiple insert statements with protocol 3
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
We've released the 4.95.152 build which contains the implementation of the 'Unprepared Execute' connection string parameter.
The new build can be downloaded from
http://www.devart.com/dotconnect/postgr ... nload.html
(the trial version) or from Registered Users' Area (provided that you have an active subscription):
http://secure.devart.com/
For more information on improvements and fixes available in the 4.95.152 version, please refer to
http://www.devart.com/forums/viewtopic.php?t=18591
The new build can be downloaded from
http://www.devart.com/dotconnect/postgr ... nload.html
(the trial version) or from Registered Users' Area (provided that you have an active subscription):
http://secure.devart.com/
For more information on improvements and fixes available in the 4.95.152 version, please refer to
http://www.devart.com/forums/viewtopic.php?t=18591
In Entity Framework v4 using dotConnect for Postgres 4.95.152 build why do I still have to set PgSqlEntityProviderServices.UnpreparedCommandExecution property to true in code when I have it set to true in the connection string. I thought having it set on the connection string would eliminate using the Static Method within code to set it.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Thank you for your report, we've reproduced the issue. The 'Unprepared Execute' connection string parameter affects PgSqlCommands only if the PgSqlConnection object is created directly. I.e., the following code creates a PgSqlCommand object that will be executed unprepared:
As for connections created using the DbProviderFactory component, we will investigate the problem and inform you about the results here.
Code: Select all
PgSqlConnection connection = new PgSqlConnection();
connection.ConnectionString = connectionString;
connection.Open();
DbCommand command = connection.CreateCommand();
[Devart]
As for connections created using the DbProviderFactory component, we will investigate the problem and inform you about the results here.
Have the issue with DbProviderFactory and the 'Unprepared Execute' been resolved yet. I am using dotConnect for Postgres 5.0 Beta, and I not longer have to set the Static Method, but the performance is pretty bad when I have the 'Unprepared Execute' connection string parameter set to true.
Thanks,
Charlie J.
As for connections created using the DbProviderFactory component, we will investigate the problem and inform you about the results here.
Have the issue with DbProviderFactory and the 'Unprepared Execute' been resolved yet. I am using dotConnect for Postgres 5.0 Beta, and I not longer have to set the Static Method, but the performance is pretty bad when I have the 'Unprepared Execute' connection string parameter set to true.
Thanks,
Charlie J.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Could you please describe these situations in more details? I will send you a test project in a letter, please check that it was not blocked by your mail filter. Please try running the sample and tell us what should be changed in it to reproduce the problem with a low performance. The table used in the sample is defined as
CREATE TABLE fetchtest
(
id bigint,
f_char character varying(1)
)
I have reported this problem before and it was fixed. Now it is back when I use protocol 3, Unprepared Execute = true, and DBProviderFactory. You can email the test project to [email protected]
Thanks,
Charlie J.
Thanks,
Charlie J.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
When I run the sample that you sent me with Protocol=Ver20, both Prepared and Unprepared took about 4 seconds. When I run the sample with Protocol=Ver30, both Prepared and Unprepared took about 16 seconds. I am using Postgres 8.4.1. Protocol=2 seem to be 4x faster than Protocol=3. So this is back to the orginal problem on this thread.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Ok. I understand. Thanks. So the fixed you mention that will be ready this week, will fix the performance problem for using DBProviderFactory.
[Devart]
We have fixed the problem with Unprepared Execute for connections created using DbProviderFactory. The fix will be available in the nearest build, which we plan to release next week.
[Devart]
We have fixed the problem with Unprepared Execute for connections created using DbProviderFactory. The fix will be available in the nearest build, which we plan to release next week.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
We have released the new 4.95.180 build of dotConnect for PostgreSQL. You can download it from
http://www.devart.com/dotconnect/postgr ... nload.html
(the trial version only) or from Registered Users' Area (provided that you have an active subscription):
http://secure.devart.com/
For the detailed information about the improvements and fixes available in dotConnect for PostgreSQL 4.95.180, please refer to
http://www.devart.com/forums/viewtopic.php?t=19239
http://www.devart.com/dotconnect/postgr ... nload.html
(the trial version only) or from Registered Users' Area (provided that you have an active subscription):
http://secure.devart.com/
For the detailed information about the improvements and fixes available in dotConnect for PostgreSQL 4.95.180, please refer to
http://www.devart.com/forums/viewtopic.php?t=19239