I have tried as many ways to implement this trigger that I can think of, and those that have been suggested. One of those suggested had the join in it.

I do not issue a SQL statement so to speak, but I will pull parts of previous thread entries to help explain. ...

----------------------
I have tried to whittle the situation down as much as possible. I have created an empty test DB, and in that DB I have created 2 tables, Table1 and Table2. Each has a Key ID field and 2 data fields, TT1ID, TT1Data1, TT1Data2 etc. Table2 has no other features; I have created the trigger only on Table1:

Create Trigger Testing on dbo.Table1
For Insert, Update
As

Declare @Data1 char(10)

Set @Data1 = (Select TT1Data1 from inserted)

insert into Table2 (TT2Data1) Values (@Data1)

I open (return all rows) both tables in Enterprise Manager. I enter a row in Table1 manually, then another, then another. When the tables start both empty, and therefore have ID fields that are in 'sync', there is no problem with the expected behavior of the trigger. The data entered into Table1 is inserted into Table2 OK.

Table1, however, has the very strange behavior of having all of its ID fields being '0, 0, 0, ...'. If I 'run' Table1, it will correct the ID fields as '1, 2, 3, ...' .

If I manually insert a row into Table2, so that the ID fields are no longer in sync, then manually insert a row into Table1, the Table hangs up, and I have to 'run' the Table again to get it to clear and fix itself.

This seems as basic as can be, and I know that we put all of the patches to SQL that we could find as recommended when we reinstalled SQL several weeks ago. It would help to know if someone is able/not able to recreate this problem on their system.

------------------------

When I use a script, as in Query Analyzer, there does not seem to be a problem.

When I open Table1 in Enterprise Manager (return all rows), then put the cursor in the TT1D1 data entry field and enter somthing, then there is a problem. The problem corrects itself if 'run' is invoked on Table1.

The planned interface for the original developement DB (where the problem 1st appeared) is currently an MS Access project. In there, entering data in the problem field produces an error which requires the form to be refreshed to correct.

Remember that before the problem presents itself, an entry must be made in Table2, unassociated with Table1.