Update: [AccessD] #Deleted#-Problem (Cross-posted)

Using SQL Profile I found that Access indeed uses 'SELECT @@IDENTITY' to get
the ID of the newly inserted record.
Unfortunately this will return the new ID-value from table B.

Using Scope_Identity could solve the problem. Is there a way to tell Access
or the ODBC-Driver to use Scope_Identity instead of @@INSERTED?

Michael

-----Ursprüngliche Nachricht-----
Von: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]Im Auftrag von Michael
Brösdorf
Gesendet: Freitag, 2. Juli 2004 14:50
An: Access Developers discussion and problem solving
Betreff: [AccessD] #Deleted#-Problem (Cross-posted)


Dear group,


I have a problem with my Access2000-App. The Backend is SQL Server 2000

A bound form is linked to Table A. Table A has an insert-trigger, that
creates a record in table B.
Both tables have an ID-Field (A_ID and B_ID).

Whenever I save a new record in the bound form, it either immediately
displays #Deleted# in every field,
or displays an old record(!).
However, the new record is created correctly.

There's a knowledgebase article, describing that problem. It states, that
Access tries to re-select the
new record using the ID value. It looks like that it is using the ID-value
of table B instead that of table A to do the re-select. If it finds a record
with that ID it displays that in the new row on the bound form. If it does
not find it, the form displays #Deleted#.

Is there any way to tell the trigger on table A not to return the ID of the
new record in table B?

Michael




--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com