Seemless Interactive UI Updation

  • Thread starter Thread starter rawCoder
  • Start date Start date
R

rawCoder

Dear All,

Problem:
Need to seemlessly update a DataBound Datagrid (WinApp) whenever the data in
the attached Table changes from different appDomain.

Current Solution:
Using Triggers, Extended Stored Procedure, ESP DLL, and Sockets intimate the
UI to call Refresh on Dataset.
Problem in pri sol:
In above scenario Refresh( ) doesnt remove rows (as in case of deletion of
some record)- Clear( ) is therefore required which is cumbersome.

Secondary Solution:
Using triggers , an Extra Table and a Derived DataSet for Refresh( ) -
update only the changed rows. (2 many modifications required)

P.S.
Sorry for possibly illegal Cross Posting :-(
Cant use Notification Services as they aint free.
ADO.NET 2.0 is fine but current version is preferable.
Please focus on primary problem first. :-) wud luv 2 c new sol instead of
mod in old sol

Any Ideas , Any Suggestions, Any Reference .. All's Welcome.

Thank You.
rawCoder
 
RawCoder,

I do not think I have an answer, however I get the idea you are making a
connected dataset. Is that the challenge? The attached Table in your message
is a "database table".

Cor
 
Sorry Cor if I was not clear.

Its a simple DataBound DataGrid.

It is bound to a dataset referring to a table in the database.

When there is some data change in the DB Table -
i.e. when some row is added changed or updated in the DB Table from some
other app or form SQL Enterprise Manager
then the DataSet doesnt get updated automatically - which is natural as the
DataSet is disconnected
and hence consequently the grid doesnt get refreshed.

That was in essense the basic problem.

HTH
rawCoder
 
Unfortunately, this will absolutely kill any kind of scalability.

To the OP, you might as well use SQL notification services. Yes, they
are not free, but based on what you said you had to do in order to acheive
the same thing (trigger, sp, sockets, etc, etc) I would take the ease of
maintainability over the cost (whatever that might be, I can't imagine it is
that much more costly performance wise than your solution) that SQL
notification services incurs.

Hope this helps.
 
Back
Top