Re: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs
От | Byron Nikolaidis |
---|---|
Тема | Re: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs |
Дата | |
Msg-id | 357FFD63.2329E3FA@insightdist.com обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs ("Jose' Soares Da Silva" <sferac@bo.nettuno.it>) |
Список | pgsql-interfaces |
Hi, After some testing with the ROWVER stuff, I have come up with the following and wanted to see what people thought about it: What I have now is if you have a timestamp type column and its field name is "timestamp", the driver will report it as a ROWVER column in SQLSpecialColumns. This causes Access to use it as a versioning column. Does this seem too restrictive? Do you have other ideas of what should constitute a versioning column? I think the field name should be agreed upon and fixed in the driver, don't you? The other caveat about this method is that you would have to supply a trigger to update this 'timestamp' field on INSERT and UPDATE. One of the things I can't get around in Access is using a column in SQLSpecialColumns that does not appear in SQLColumns (i.e., a pseudo-column). For example, even if we had a 'tmin' column (I know it was removed for 6.3.2), or wanted to try using the 'xmin' column, we couldn't use it as a pseudo column. We would have to display the column. Access spits out an ugly message when I try to use a pseudo-column ("Table TMP%#MAU@ already exists"). I have tested other types besides timestamps, like int4, and they seem to work fine as a versioning column. So, we could use the postgres 'xmin' column, if we displayed it in SQLColumns. It seems to always update so you wouldn't have to worry about a trigger. I'm not sure what end-users would think about seeing these ugly columns in Access? Any thoughts about that? Please give me some feedback on this. Byron
В списке pgsql-interfaces по дате отправления: