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
