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
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

Thread
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