Devart Forums

The issue is associated with the fact that Code First uses a different approach to create a command, and our functionality did not cover this use case.
The workaround I have already suggested allows for these peculiarities.

But my use case have worked before and I have verified that it worked when you said that it was fixed and sent me a test application that I verified that worked. Did it ever work or

Thanks,

Charlie J.

Is the problem resolved with using PgSqlEntityProviderServices?
We are working on the improvement of the UnpreparedExecute connection string parameter.

Yes. The problem is resolved by using the PgSQLEntityProviderServices in the constructor of the EF Context.

When will the UnpreparedExecute connection string parameter function the same way without put this workaround in the constructor of the EF Context?

Thanks,

Charlie J.

We will post here when this functionality is implemented.
The investigation is in progress.

Any updates on When will the UnpreparedExecute connection string parameter function the same way without put this workaround in the constructor of the EF Context?

Thanks,

Charlie J.

We are working on this issue. We will notify you about the results as soon as possible.

The bug with assigning the UnpreparedExecute option from connection string to the command is fixed. We will post here when the corresponding build of dotConnect for PostgreSQL is available for download.

New build of dotConnect for PostgreSQL 5.50.228 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=22166 .