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