MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Steve Procter Date:March 29 1999 6:19pm
Subject:Re: mySQL/ODBC/Microsft Access problems
View as plain text  
At 14:36 29/03/99 +0300, you wrote:
>>>>>> "Ed" == Ed Carp <erc@stripped> 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
>>> at the backend using mysql I can see that it has successfully inserted
>>> the timestampfield and primkeyintfield.  However Access simply displays
>>> 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.
>Can you check the queries that Access generates when this happens ?
>Could the problem be something with timestamp and null values ?

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.


Dive Today Magazine

mySQL/ODBC/Microsft Access problemsSteve Procter28 Mar
Re: mySQL/ODBC/Microsft Access problemsEd Carp29 Mar
  • Re: mySQL/ODBC/Microsft Access problemsMichael Widenius29 Mar
    • Re: mySQL/ODBC/Microsft Access problemsSteve Procter29 Mar