Sharing Data between threads

Charlie Brown <cb****@duclaw.comwrote in news:1194892903.889392.257060
@v65g2000hsc.googlegroups.com:

My questions are, can 2 threads
loop through a dataset at the same time?

Yes, but you'll have to deal with concurrency issues. If two threads are
updating the data, which thread takes precendence? What if two threads
updating the same field at the same time?

Can my background process
create a copy of the database and then merge the copy?

How large is your database? What sort of updates are you applying?

Can my
background process download a new set of data and copy it over the
current dataset?

Yes, but you'll need to deal with concurrency issues.

On Nov 12, 3:41 pm, Spam Catcher <spamhoney...@rogers.comwrote:

Charlie Brown <cbr...@duclaw.comwrote in news:1194892903.889392.257060
@v65g2000hsc.googlegroups.com:

My questions are, can 2 threads
loop through a dataset at the same time?

Yes, but you'll have to deal with concurrency issues. If two threads are
updating the data, which thread takes precendence? What if two threads
updating the same field at the same time?

Can my background process
create a copy of the database and then merge the copy?

How large is your database? What sort of updates are you applying?

Can my
background process download a new set of data and copy it over the
current dataset?

Yes, but you'll need to deal with concurrency issues.

Thanks for the reply. The dataset is small, say around 2000 rows, 6
columns, max. The UI searches for a specific row every few seconds
and updates a boolean value. The background task loops through the
dataset at a set interval and updates the database by calling
SqlCommand.ExecuteNonQuery on the rows that have been affected. Once
all affected rows have been updated, it creates a new dataset and then
copies over the original.

The only problem with this approach would be if the UI updates the
dataset after the merge completes, but before the new data is copied
down from the database. Basically I would lose that data.

Charlie Brown <cb****@duclaw.comwrote in news:1194901576.798306.28180
@v2g2000hsf.googlegroups.com:

Thanks for the reply. The dataset is small, say around 2000 rows, 6
columns, max. The UI searches for a specific row every few seconds
and updates a boolean value. The background task loops through the
dataset at a set interval and updates the database by calling
SqlCommand.ExecuteNonQuery on the rows that have been affected. Once
all affected rows have been updated, it creates a new dataset and then
copies over the original.

Datasets provide events for changed rows/columns/cells. Perhaps you can
hook into these events to act on the changes rather than polling on the
dataset?

The only problem with this approach would be if the UI updates the
dataset after the merge completes, but before the new data is copied
down from the database. Basically I would lose that data.

You'll need to do some synclocking to prevent concurrency issues.