| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-01-04 : 09:30:08
|
| Wiktor Torq writes "there comes the problem:server-side dynamic recordsets seem very seductive. I wrote a short VBprogram for test purposes only. The program creates such recordset andreveals some short notifications about recordset's events.It works great: when I try to change values of some fields, events are fired(WillChangeXXXX and XXXXChangeComplete etc).But when more instances of the application are started (probably even byvarious users on various machines) and one of them modifies data, thechanges are visible to the other instance when it explicitely scrollsthrough the recordset. For example, when user A changes the data with ID=1024, and theuser B is views the data on some kind of a grid, he's completely unable tofind out that the data has been changed (until he repopulates the grid againwhich involves walking through the recordset).My question is:Is it possible to have some kind of global notification that the data has beenchanged (when one instance of application changes some data, everyone wouldbe notified that the data has been changed) like the notification the user gets when he changes the data by himself?Am I following the right path? Maybe the idea is totally incorrect?Any help would be appreciated.Wiktor" |
|
|
mfemenel
Professor Frink
1421 Posts |
Posted - 2002-01-04 : 09:59:37
|
| If you use a keyset cursor, you should be able to see edits and deletions within the recordset.Mike "A program is a device used to convert data into error messages." |
 |
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-01-05 : 01:01:03
|
| mFemenel, Dont you think until he refreshes the grid ,he cant c the updated data?.----------------------------Anything that Doesn't Kills you Makes you Stronger |
|
|
|
Rafiq
Starting Member
25 Posts |
Posted - 2002-01-05 : 01:28:16
|
| Hi,We are handling like this problem. What we do? I have created a table (KEYONLY).It have some related fields.When user A fetched a record, I have stored some data (like TableName, UniqueColumn value and Currentusername) into KEYONLY table.When user B try to fetching that same record,check that record using or not based on KEYONLY table, If its using anybody,system raise notice message (like "The specific user using this record. Please try after some time later") to user B.The User A complete the tranaction, remove that specified row in KEYONLY table. When user B try to fetching this record, it will comes with newly modified data.What you feel about it?Regards,Rafiq |
|
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-01-05 : 01:36:40
|
Rafiq , that sounds fine , if you want to do some modifications and you issue a request. but Victor wants (as i understand it) is he if already has pulled the data in a grid. after he pulls the data if there are any modification done on the data , he has to Automatically get a notification about the modification or the data should be refreshed( just like our own www.sqlteam.com/active.asp  ) . but that is only possible ,if you keep refreshing the data. you can use a timer control and keep refreshing your grid on a specific interval.if any1 has a better way of doing it, i would be intrested in it.HTH----------------------------Anything that Doesn't Kills you Makes you Stronger |
|
|
|
Lavos
Posting Yak Master
200 Posts |
Posted - 2002-01-05 : 02:38:33
|
| Well, I haven't gotten around to learning about that part of SQL Server yet, but with it's ability to create COM objects you could theoretically setup a callback object.Since I don't know the system well yet, I'm not totally sure how it would work, but essentially the client would have to advertise a com interface that the server would grab when the client registers itself with the server. Then, you could use triggers to do callbacks on the object similar to the observer pattern from the Design Patterns book. Depending on your needs, it could be incredibly complex with all sorts of fun criteria to evaluate before doing the callback, or as simple as triggering on every modification.Of course, this assumes that sql server can use DCom to get a remote object. Even if it can't, then you could always wrap everything in extended stored procedures which shouldn't have a problem.It looks like I might have a research project this weekend :)Of course, there is probably a better way to do it that I don't know about yet, but I can see some great tradeoffs for using this approach over periodically refreshing the data set. The administration overhead looks like it's going to be a killer though."O Theos mou! Echo ten labrida en te mou kephale!" |
|
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-01-05 : 02:50:41
|
| Lavos, that sounds pretty nice, yeah it is complex. my solution is simple but very inefficent.Rafiq, a second thought about the way you are handling notification sounds very inefficent. for eg:a user might pull a record for modification and might take its own sweet time to modify the data and issuing the final request of update. and Even might decide to Cancel it. till that time this particular record can'b be accessed!!!!. if supposing they can access to only read it, when the data is modified by the first client who has requested for a update. then Again v fall back on the same case , how will you notify the Read accesses clients about the new update's?.----------------------------Anything that Doesn't Kills you Makes you Stronger |
|
|
|
Rafiq
Starting Member
25 Posts |
Posted - 2002-01-05 : 04:19:16
|
| Nazim, Yes your point is correct. I will try to solve this problem. If i solve it. i will tell you.Thanks.Rafiq------------------------------------If you think, you can do anything... |
|
|
|
Onamuji
Aged Yak Warrior
504 Posts |
Posted - 2002-01-06 : 11:56:51
|
| This would require a constant connection to a "DATA SERVER" ... preferably a service running on a server that then handles requests for data access and changes to the database. On change successful it could send a request to the clients that are connected asking them to refresh their data or you could just tell them that you are sending the updated record(s).Web services may work well for distributing the records. Or you could just connect to the page asking for the most recent changes. There is no real way to sync data changes unless you write your own data server.just my 2 cents...- Onamuji |
|
|
|
Lavos
Posting Yak Master
200 Posts |
Posted - 2002-01-06 : 12:51:21
|
| I had thought about suggesting routing everything through a data server, but that might not work if the database itself changes some data through replication or whatever else. I did work on a proof of concept last night with object callbacks, which didn't work quite as well as I hoped (It'd work great if I took the time to make the function calls asynchronous) and came up with a pretty good alternative method.COM+ Queued components*. You need a local ActiveX dll or exe for sql server to use (Or you can wrap everything in extended stored procedures. I don't have the test environment to really see which is better.) which sends messages through a queue to another process. That process then processes the message and sends a new message to the clients that have registered themselves as interested.I don't have DSL quite yet, so I haven't grabbed all the SDK's yet, so I can't build a test prototype, (I really need to spring for a MSDN membership, maybe next week.) but in theory this would work pretty good.For the record, when using object callbacks, you better make sure that the method call is asynchronous, otherwise it's going to be ugly :O* Or you can use MSMQ if you aren't using Win2000.----------------------"O Theos mou! Echo ten labrida en te mou kephale!"Edited by - Lavos on 01/06/2002 12:57:59 |
|
|
|
|
is ADO able to inform me that server-side dynamic recordset data has been changed?