Devart Forums

I have a strange problem. In my UTF8 encoded database I have several tables that have a "Created Date" TIMESTAMP field. In my IDE I set these fields to NOW. If I then save the created rows, and then try to edit or delete them in the IDE, and then save again I immediately get thrown a concurrency error. If I take the Created Date field out of the equation it all works fine so I know the problem specifically relates to that. All I know is, in my IDE if I look at the date field it says "29/11/2007 1:30:28 PM" whereas in the database it's stored as "29/11/2007 13:30:28". I'm amazed this would make a difference but I can't think of any other explanation.

Anyone have any ideas?

The other thing I've noticed is that when the Created Date gets saved to the database it is always shown as one second behind the one in the actual dataset! I have no explanation for this, however once again I don't know if that's causing the concurrency error, because if I manually change the Created Date in the database to increase the time by a second to match what's shown in the IDE it STILL throws a concurrency error on it.

I have no idea what's going on and this is driving me crazy since the exact same code works perfectly in databases other than pgSQL.

Phew! Finally resolved the issue. It was because of a bug in the way the CoreLabs provider seems to handle timestamps. Ordinarily it works fine, however I imported my database from Access and a number of fields came across as TimeStamp(0) type fields. After many many hours of struggling a colleague mentioned that his database simply had a TimeStamp field with no (0) and it worked fine. Sure enough changing the database field type to just TimeStamp worked perfectly.

Something I think for you guys at CoreLabs to keep an eye on.

Thank you for information. We will investigate the issue and change the behavior if necessary.