Concurrency Violator
===============
This application demonstrates the creating and handling of concurrency violations.

A concurrency violation occurs when the following sequence of events occurs.

1. User 1 reads record A.
2. User 2 reads record A.
3. User 1 changes record A, and saves changes to the database.
4. User 2 changes record A, and attempts to save her changes to the database.

But ADO.NET knows that the data in record A has changed since User 2 read in from the database, and therefore that saving the changes made by User 2 may overwrite changes made by User 1.  As a consequence, it issues a concurrency violation and refuses to save the second set of changes.

In this app, two copies of a program called "Data Editor" are launched.  To create a concurrency violation, to the following:

1. Load products records into both copies;
2. Edit a few records in the first copy, then click <Update Database> to save the changes.
3. Edit some of the same records in the second copy, then click <Update Database>.

Because the changes affect records that have changed in the back-end database since they were loaded for the second form, the saves will fail and the local copies of the records involved will be flagged as having a concurrency error.  The Data Editor app uses that information to pass those records to another form, frmShowRecordVersions, where they are displayed in a DataGrid.  Also displayed there are the corresponding server versions of the same records.  You (playing the role of end user) then have a change to overwrite the server versions with the local copies whose changes were initially rejected.
