DataSet Merge Method Research (from JCWNet)

xiaoxiao2021-03-06  74

In ADO.NET, we usually use the DataSet Merge method when merging two identical or similar DataSet objects. This method has multiple overload versions, before introducing it before reviewing the MERGE method, the following is the MSDN Merge method instructions:

Merge methods are used to combine two DataSet objects that are approximately similar. Merged is usually used to merge the most recent changes in the data source into an existing DataSet. This allows the client application to have the DataSet that refreshes the latest data in the data source. Usually call the MERGE method at the end of a series of processes, these processes involve verifying changes, eliminating errors, using changing update data sources and finally refreshing existing DataSets.

In the client application, there is usually such a button, and the user can click it to collect the changed data and verify it, and then send it back to the intermediate layer component. In this case, the GetChanges method will be first called. This method returns another DataSet that is optimized for verification and merge. The second DataSet object contains only changed DataTable and DataRow objects, resulting in the subset of the initial Dataset. The subset is usually smaller, so it can be passed back to the intermediate layer assembly more efficiently. The intermediate layer component will then update the initial data source by using the stored procedure. The intermediate layer can then be sent back to a new DataSet, including the initial data and the latest data in the data source (by running the initial query again); or it can send a subset that contains all changes to which it is performed from the data source. (For example, if the data source automatically creates a unique main key value, you can propagate back to the client application.) Which Merge method can use the MERGE method to multi-retracking back to the initial Dataset of the client application .

When the new source Dataset is merged into the target, the DATAROWSTATE value is unchanged, modified, or deleted any source line matches the target line with the same main key value. The DATAROWSTATE value is the source line of the ADDED to match the main key value and the new target line as the new source line.

According to the above description, we know that the MERGE method is compared with the primary key value of the row in the merging of the two data sets. This will not have any problems when adding a new row to the data set, and there will be no problem in the case of modifying the row and does not modify the main key value, but if you change the value of the primary key when you change the line, then the question is Come here ... let's explain the following:

A Products table structure under SQL Server is as follows:

Column name

type of data

Description

Code

nchar

Product code (primary key column)

Name

nvarchar

Name name

Unitprice

Numeric

Product single price

Generate a corresponding productsData.xsd structure in .NET is as follows:

Column name

type of data

Description

Code

String

Product code (primary key column)

Name

String

Name name

Unitprice

Decimal

Product single price

According to the MSDN, we will usually practice when you add or modify the data through ProductsData through ProductsData, as follows:

// Create a new data set to save the changes to the master data set

ProductsData DataSetchange;

DataSetChanges = (ProductsData) (ProductsData);

// Check if any changes have been made

IF (DataSetChanges! = NULL) {

Try {

// Need some changes, so try to call Update method

// and pass the data set and any parameters to update the data source

UpdatedataSource (DataSetChanges);

ProductsData.mege (DatasetChanges);

ProductsData.acceptchanges ();

}

Catch (system.exception EUPDATE) {

Throw EUPDATE;

}

}

The above code is based on the data form generated by VS.NET, which is based on the above code to add a line of data to the data set to the data set:

Code

Name

Unitprice

1001

Gold sand chocolate

120.00

No problem, let's modify this line of data and update it. Here we change the code to 1002. After the update, the result data does not change the value 1001 of the original row code column to 1002 as much as we expected, but add a line:

Code

Name

Unitprice

1001

Gold sand chocolate

120.00

1002

Gold sand chocolate

130.00

Note: Usually we are rarely changing the main key value, but in the case where the code is not used, it is generally allowed to change the Code, especially in the system implementation.

The reason for the above problems is not surprising, according to the principle of the MERGE method, this is true, but this is our undesirable result, how to solve it, is it allowed to change the primary key, but it is not in line with the actual. How to solve it?

Since it is necessary to use the MERGE method, then it is doing the principle of mergergery data. If we don't let the re-keys, we will not change the primary key. We can add more extra primary key IDs to the PRODUCTSDATA for the front desk and put it the autotoincrement. Set to True, change the original primary key column code to the Key column, as for the source table in the background SQL Server does not make any modifications, then modified as follows:

Column name

type of data

Description

Id

Int

Automatic growth column (primary key)

Code

String

Product code (Key) Name

String

Name name

Unitprice

Decimal

Product single price

With such a change, because the ID is an automatic self-acquired column, we do not modify its value so that we can change the value of the Code column at will, and the MERGE method is compared by the ID case due to the comparison data. It will not appear in front of the problem.

Postscript: This is the first article I wrote after the blog applied for the blog application. It is a bit more than a bit that I feel written. It is only the last few lines that have been written so long. This may be only for those .NET masters just Sculptor small skills, so let masters laugh.

转载请注明原文地址:https://www.9cbs.com/read-109448.html

New Post(0)