Message-Id: <357FFD63.2329E3FA@insightdist.com>
Date: Thu, 11 Jun 1998 11:53:07 -0400
From: Byron Nikolaidis <byronn@insightdist.com>
Mime-Version: 1.0
To: "Jose' Soares Da Silva" <sferac@bo.nettuno.it>
Cc: Hannu <hannu@trust.ee>,
	interfaces postgres <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] Re: M$-Access'97 and TIMESTAMPs
References: <Pine.LNX.3.96.980611112320.3708A-100000@proxy>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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