Re: Date precision problem
От | Martijn van Oosterhout |
---|---|
Тема | Re: Date precision problem |
Дата | |
Msg-id | 20020418135015.A15314@svana.org обсуждение исходный текст |
Ответ на | Re: Date precision problem (noy <noyda@isoco.com>) |
Список | pgsql-general |
On Wed, Apr 17, 2002 at 06:34:49PM +0200, noy wrote: > Thomas Lockhart wrote: > > > > Could you be more specific about the problem? I first interpreted this > > as a problem with now(), but now that I read this again you are talking > > about updating fields so that is not the actual test case is it? > > DEBUG: StartTransactionCommand > DEBUG: query: BEGIN > DEBUG: ProcessUtility: BEGIN > DEBUG: CommitTransactionCommand > DEBUG: StartTransactionCommand > DEBUG: query: UPDATE "test" SET "name"='name 1 update 4' WHERE "id" = 1 AND > "name" = 'name 1 update 3' AND "last_update" = '2002-04-17 16:40:44.548' > DEBUG: ProcessQuery > DEBUG: CommitTransactionCommand > DEBUG: StartTransactionCommand > DEBUG: query: ROLLBACK > DEBUG: ProcessUtility: ROLLBACK > DEBUG: CommitTransactionCommand Ok, what's happening is that Access is trying to update the row and the only way to identify the row is by matching all the fields. Access is truncating the date, hence it can't update. Solution: define a primary key on the table and tell access to use that. Then it won't rely on properties of the date types to update successfully. You may be able to fix it on the postgres by telling it to use a date type that does not store nanoseconds. -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Ignorance continues to thrive when intelligent people choose to do > nothing. Speaking out against censorship and ignorance is the imperative > of all intelligent people.
В списке pgsql-general по дате отправления: