Devart Forums

Thank you for the update.
Keep safe @devartteam

Thanks. Having done some more reading, we now prefer 6.3 anyway and will be sticking there.

Hi,

Is Entity Framework Core 3.0 supported at the moment or is support to come in the future?

Just checking the behaviour we are getting isn't unexpected (using dotConnect for PostgreSQL 7.14).

Was starting a new project with Core 3.0. We tried out EF Core 3.0 first, but ran into a missing method exception when calling 'UsePostgreSql'.
ie
var optionsBuilder = new DbContextOptionsBuilder<myModel>();
optionsBuilder.UsePostgreSql(myPgSqlConnection, (a) => { ... });

I've used the new EF 6.3 support successfully with Core 3.0 so for now we are starting with that. However ideally we would be using EF Core. So if the status of Entity Framework Core 3.0 support could be clarified that'd be great

Thanks

Thank @Shalex , confirming the internal build has fixed the issue for us.

Hello,

We've just been looking at upgrading to VS2019 and as part of this were upgrading our Dotconnect for Postgresql version to 7.13.1366.

We've noticed what we think is a change when reading datetimetz fields. In Version 7.11.1190 on database reads, the DateTimeKind of any DateTime we read would be Local. Now, the DateTimeKind is returning as Unspecified.

We have not configured PgSqlLocalization.TimeZone, so according to the documentation (https://www.devart.com/dotconnect/postg ... eZone.html )
the previous behavior should still be the case? Hence is this a bug?

We have PostgreSql configured to UTC, the application server set to local time and as noted above have not configured PgSqlLocalization.TimeZone.

Please let me know if you need any other detail?

Great my unit test now passes, thanks!

Great thank you

Hi,

We are experiencing a bug in the dotConnect provider for Postgresql (7.3.X , though I have tested a trial of latest as well).

Example scenario:
1. Set host to Australian Eastern Standard Time.

2. Insert a record on the day daylight savings had switched on, which here this year was Sunday Oct 4.
i.e. cmd.CommandText = "INSERT INTO \"MyTable\" (\"MyDate\") VALUES ('2015-10-04 08:24:15+11')";
(daylight savings here is +11, while standard time is +10).

3. Retrieve the date from the db.... i.e. something like
using (var cmd = new PgSqlCommand())
{
cmd.Connection = _pgConn;
cmd.CommandText = "SELECT \"MyDate\" FROM \"MyTable\"";
using (var reader = cmd.ExecuteReader())
{
while (reader.Read())
{
dateReturned = reader.GetDateTime(0);
}
}
}

Assert.That(dateReturned, Is.EqualTo(DateTime.Parse("2015-10-04 08:24:15+11")));
//Fails! Expected: 2015-10-04 08:24:15.000 But was: 2015-10-04 07:24:15.000

It has treated the date like it was before DST when moving it back to local.

I have a nunit test reproducing the issue if you need. This is impacting a production system for us. The same test works fine in npgsql.

The problem only occurs on the date daylight savings was switched on or off, only when the timezone of the machine is set locally (I've only tested AEST, but suspect it is general issue), and not for the full day (I think when the date in UTC falls onto the same date here, the problem stops).

Hi there,

We have noted some interesting behaviour using TransactionScope that'd we'd like to clarify.

Basically we are seeing every transaction being committed as a prepared transaction even if all the activity within TransactionScope was on a single connection, even if just a single write for example.

As in: We have enlist at the default of true. Transactions seem not to work with it false?

Additionally, rarely (but of high impact when it does happen), we have seen a prepared transactions being created but not committed, leaving a table locked until we manually release the prepared transaction. Not really sure how this could be happening given the PREPARE TRANSACTION and COMMIT PREPARED all spit out at once.
Basically we then start piling up connections til the entire db becomes locked.

I'm aware that Transaction Scope Local=true; will turn off prepared transactions with TransactionScope, but we do have a few instances in the future that we will want them. It seems odd that TransactionScope is so coupled to prepared transactions. Is this behaviour expected?

Also any ideas how we would potentially end up with an orphaned prepared transaction given the above simple update?

Thanks.