Shredding two document types to the same table is, in general, a scenario that is not supported. The reason is that DBXL follows a delete and re-shred model when updating documents that already exist. In other words, when you submit a new document, DBXL deletes old rows and creates new rows in the target database corresponding to the mapping defined in DAT. In order to keep track of these shredded rows, documents and rows are added to a cross-reference (X-Ref) table. When you open a document, perform changes and then submit it back to DBXL, the original rows in the target database are deleted, and DBXL inserts new rows. This approach is simple and provides support for more database mapping scenarios. Because it does not have to perform comparison checking, it is also a quicker approach.
The problem arises when shredding to a table that uses an IDENTITY column as primary key. When one Document Type (DT1) creates a Document and then another Document Type (DT2) edits it, the cross reference tables for DT1 will still have the values of the original submitted document. So, when you perform an edit with DT2 it will try to delete rows for those values, fail, and then insert new (and therefore) duplicate rows.
Let’s walk through an example. This example shows a successful submission with one Document Type first followed by an example of how two Document Types shredding to the same table will not work.
Workaround: If you are using the DocID of the Document as the primary key in the target table, you should be able to update the same table from multiple Document Types, since the DocID does not change with each submit. However, each of the Document Types must map all of the columns of the table. Any columns that a Document Type fail to map will be set to NULL with the next submit.