At 07:55 AM 3/23/99 -0500, you wrote:
> Hi all, I was wondering if anybody had come across this one yet . .
> I am using Access97 with ODBC 2.50.22 and MySQL 3.22.16a-gamma for
>pc-solaris2.7 on i386
> (recently upgraded from 2.50.18 and 3.21.xx in an attempt to overcome the
>same problem) and am unable
>to edit a row in a table (a mysqldump of which lies below). I can add
>records, just not edit them.
> Access gives the error message:
> "Write Conflict"
> "This record has been changed by another user since you
>started editing it. If you
> save the record, you will overwrite the changes the other
> "Copying the changes to the clipboard will let you look at
>the values the other user . . ." yada yada.
> This table should not be in use by anybody else, as the database is
>in early development,
>and I'm the only developer.
> For reference sake, the database has a number of tables, all of
>which have "NPB int(10)" as the primary key.
>Could this be caused by a lock on another table, given the identical key
># MySQL dump 5.12
># Host: localhost Database: PDP_Pub
># Server version 3.22.16a-gamma-log
># Table structure for table 'PPEActivity'
>CREATE TABLE PPEActivity (
> NPB int(10) DEFAULT '0' NOT NULL,
> TeamLeadEngg smallint(5) DEFAULT '0',
> PPEStatus tinyint(3) DEFAULT '0',
> PhaseChg0_1 datetime DEFAULT '0000-00-00 00:00:00',
> PhaseChg1_2 datetime DEFAULT '0000-00-00 00:00:00',
> PhaseChg2_3 datetime DEFAULT '0000-00-00 00:00:00',
> PhaseChg3_4 datetime DEFAULT '0000-00-00 00:00:00',
> PhaseChg4_5 datetime DEFAULT '0000-00-00 00:00:00',
> POType tinyint(4) DEFAULT '0',
> PPEAction text,
> PPEActionDate datetime DEFAULT '0000-00-00 00:00:00',
> PRIMARY KEY (NPB)
># Dumping data for table 'PPEActivity'
>INSERT INTO PPEActivity VALUES (5597,1,2,'0000-00-00 00:00:00','1999-01-01
>00:00:00','0000-00-00 00:00:00','0000-00-00 00:00:00','0000-00-00
>00:00:00',2,'complete doublelock','1999-03-15 00:00:00');
What you are missing is a timestamp type, often created on a non-refered
column name. The sole purpose for this, in access, is to put a unique
signiture on the row every time the row is updated. It expects the value of
the timestamped column to change. Itshould not be refreanced as a valid
value. In fact, SqlServer uses a byte(8) array for this value. The above
table did not work with an update statement due to access not knowing what
the signature would be and could not tell if it has been changed.
Peter B. Carter (peterc@stripped)