From: Steve Procter Date: March 29 1999 6:19pm Subject: Re: mySQL/ODBC/Microsft Access problems List-Archive: http://lists.mysql.com/mysql/1153 Message-Id: <3.0.5.32.19990329191905.00845030@divetoday.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 14:36 29/03/99 +0300, you wrote: >>>>>> "Ed" == Ed Carp writes: > >>> I then insert a row into the table from my Access Table window, only >>> filling out the textfield field. I then save it. If I then select the row >>> at the backend using mysql I can see that it has successfully inserted both >>> the timestampfield and primkeyintfield. However Access simply displays the >>> row as follows: >>> #Deleted #Deleted #Deleted >>> >>> If I close my Access Table window and re-open it the row is displayed >>> correctly. So why didn't it display it correctly when first saved away? > > >Ed> I'm wondering if there's a bug in the ODBC layer or even in Access itself >Ed> (deity knows there's enough weird bugs in Access!) - I've seen this >Ed> behavior, too - and doing a refresh from the Access window doesn't fix it - >Ed> but if I reopen the table, it works fine. > >Hi! > >Can you check the queries that Access generates when this happens ? >Could the problem be something with timestamp and null values ? > >Regards, >Monty > This problem even occurs when I simply open the linked table and insert a row, so it's not really possible to check the sql Access produces. My only way around this is on my form - to stick a bit of code into the form "before insert" to automatically insert a primary key, a bit naf but hey. But any other ideas would be great. cheers steve Dive Today Magazine mailto:steve@stripped http://www.divetoday.com