Timestamp concurrency issue

[leeottaway]

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?

[leeottaway]

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.

[leeottaway]

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.

[SecureGen]

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