This problem happens because Access doesn't have a data type that
corresponds to Bigint. When you display a table, Access will re-read every
row (by the primary key) to see if they are still there (and haven't been
deleted by an external app). Because of the data type problem, Access will
not be able to read the rows correctly so does not find them. It will
therefore think the rows have been deleted and marks them as such. As
mentioned, this problem also happens with timestamp cols. IBM have put a
workaround option so that the DB2 Client returns timestamp cols as
character. Access can handle char strings OK, so is able to display and re-
read them OK. It looks like there is no workaround option for Bigint, so
there is no simple resolution for your problem. What does work however is
to create a view on your table with the bigint col converted to character -
eg. "create view bigintview (bigintcol, col2) as select char(bigintcol),
col2 from biginttab". You can display and update this view in Access OK
(and this updates your table).
Phil Castle
On Mon, 9 Aug 2004 18:27:39 +0200, Klemens <me@privacy.net> wrote:
The linked table has a bigint in primary key columns.
I've read that service pack 8 on Jet should solve this but it didn't.
On patch1 options I only found to map timestamp to char(26) entry
for similar problems on timestamp fields but nothing for Bigint.
DB2 is UDB8.1 Fix 6 on Win2000
Are there any other solutions?
Thanks
Klemens
--
Using M2, Opera's revolutionary e-mail client:
http://www.opera.com/m2/