Finally.... I found someone who has the same problem as I do.
For the part with the duplicate record, to avoid the troublesome workaround
suggested by Microsoft, you should change your primary column's data type to
"uniqueidentifier". In another word, it's a GUID. The only problem here is,
you need to generate the GUID in you VB code and set it into the datarow.
Then, if you use Stored Procedure, you need to modify the Stored Procedure
which do the updating part by removing the part which update the primary
key.
Example,
UPDATE myTable SET PrimaryKey = @PrimaryKey, SecondColumn = @SecondColumn
should be changed to
UPDATE myTable SET SecondColumn = @SecondColumn
For the one with "An error occurred in XML Document (..,...)", everybody
seems to ignore it..... sigh. I posted this problem in more than 10
newsgroups and forums but nobody responds to it.
"GM" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Hi,
>
> I've encountered a couple of bugs in the framework, one in version 1.0 and
> one in version1.1.
>
> The first bug is one which I have seen mentioned in a couple of
newsgroups,
> but I have not seen a workaround suggested or a response from Microsoft
> regarding the problem. It occurs when you try and return a dataset from a
> webservice containing RowErrors (as you must do in order to deal with
> concurrency exceptions). An exception is thrown with the error:
>
> "An error occurred in XML Document (..,...)"
>
> This error occurs when using framework version 1.1. Due to this error, I
> switched my VS.Net project temporarily to use framwork version 1.0.
>
> However, while using version 1.0, I encountered another bug. I use the
> GetChanges()/UpdateDB/Merge process to update the database and keep the
> client-side dataset up to date. On an insert, this can result in identical
> rows (apart from IDs) being present in the dataset as the Merge() inserts
> the row returned from the database rather than merges it because it cannot
> match the ID auto generated in the client dataset with the resolved ID
from
> the database. This is overcome by setting the UpdateStatus of the row to
> SkipCurrentRow in the webservice so that the auto-identity value is
> preserved as the ID's orginal value and the row can therefore be matched
> with the row in the client dataset (see KB 313540 - PRB: Merge Method
> Creates Duplicate Records For AutoIncrement Fields). This only works for
one
> row, however, as Merge() seems to call AcceptChanges() on the whole
dataset
> being merged in after the first row is merged, so that all subsequent rows
> in the dataset are inserted rather than merged (probably because they are
> matched on ID's current value as original value doesn't exist anymore).
This
> bug appears to have been fixed in framework version 1.1, however, as the
> Merge() works fine.
>
> My problem is therefore that a fix for one bug is to use framework version
> 1.0, while the fix for the second bug involves using framework version
1.1.
> Does anyone know of any workarounds for either of these problems?
>
> Thanks in advance,
>
> Graham
>
>
|