I'm seeing these errors.  For this orchestration I am tracking in and
outbound mesages and 1 property.

Execute batch error.  Exception information:  TDDS failed to batch execution
of streams.  SQLServer: BTSQL, Database: BizTalkDTADb.Cannot insert duplicat
e
key row in object 'dta_MessageFieldValues' with unique index
 'dta_MessageFieldValues_index_uidMessage
InstanceId_nMessageFieldsId'.
The statement has been terminated..

Any idea why this is happening ?
Tim

[ Post a follow-up to this message ]

Is this a warning in the Event Log or an error?

This normally happens when a tracking stream fails to be processed on the
SQL level.   TDDS retries 10 times by
default.  In some cases, multiple threads try to write the same data into
the dta_MessageInstances table, and one of them fails because of the unique
key
constraint.

Most of the time, BizTalk stored procedures take care of identifying the
duplicate
data coming from another transaction, but in some cases this detection may
not happen.  This is when we fall back to the TDDS retry mechanism.  TDDS
retry mechanism writes to the Event Log but after a retry attempt,
everything should be fine.


Sincerely,


Everett Yang
DSI - Microsoft BizTalk Server

This posting is provided “AS IS” with no warranties, and confers no rights.
Subscribe at
http://support.microsoft.com/defaul...msdn/nospam.asp
&SD=msdn

[ Post a follow-up to this message ]

these are showing up as warnings.

I'm seeing other errors related to tracking.  I'll follow up in a new post.

Thanks
Tim

"Everett Yang" wrote:

> Is this a warning in the Event Log or an error?
>
> This normally happens when a tracking stream fails to be processed on the
> SQL level.   TDDS retries 10 times by
> default.  In some cases, multiple threads try to write the same data into
> the dta_MessageInstances table, and one of them fails because of the uniqu
e
> key
> constraint.
>
> Most of the time, BizTalk stored procedures take care of identifying the
> duplicate
> data coming from another transaction, but in some cases this detection may
> not happen.  This is when we fall back to the TDDS retry mechanism.  TDDS
> retry mechanism writes to the Event Log but after a retry attempt,
> everything should be fine.
>
>
> Sincerely,
>
>
> Everett Yang
> DSI - Microsoft BizTalk Server
>
> This posting is provided “AS IS” with no warranties, and confers no ri
ghts.
> Subscribe at
> [url]http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp[/ur
l]
> &SD=msdn
>
>

[ Post a follow-up to this message ]