|
You're not going to get a "push" notification from the server, you're going to have to check from your client application under any circumstance. My personal solution if I was to do this would be to create a separate monitoring thread that would update the visible data cache in an application in the background so as not to affect the UI thread of the application. I would let the UI then check for a flag in the data cache indicating that updates were found and update itself. That way the application performance isn't adversely affected by the checking.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
thanks for this explanation,your idea now is clear for me.
did you tried something like this before SqlDependency ?
|
|
|
|
|
I haven't used that. But it does look like a promising lead.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Any idea why the competition isn't using auto-updating grids with every instance of Sql Server? 
It's called "bad design".
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
sorry, can't get your point.may you express your idea for me please.
|
|
|
|
|
Auto-updating grids are a "pain in the ass", a "bad idea".
Imagine you editing a name, and a person on the room next to you editing the same name. Imagine Google Wave. Imagine concurrency-errors and a network that nearly collapses under the extra traffic.
Unless you are building a MMO-game, you stay away from real-time updates.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
|
The idea comes up from time to time, usually from a non-technician. Reason is that it's technically possible, and it sounds like a good idea. WarCraft can push updates in real-time, so why can't Sql Server?
Well, it can, but it's not a good idea. With someone editing in the grid, the entire grid would move (all rows!) when someone deletes the first record. Imagine the amount of network-data required, to keep all the clients up to date.
There are a whole lot of grids out there. Microsoft Access did not implement the feature, nor did the other grids. Ask yourself why.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
thanks bro for your help, I really I appreciate your efforts.
I'll tell you how I tried to solve the problems you mentioned and you please tell me
what do think about my solutions :
* About saving two records at same time I follow the following:
- grid is only for showing data, adding and editing data in a separate form.
- I added a column with datatype of timestamp in almost all database tables.
- when I show editing form to edit a specific record,I select the timestamp for this specific record (and keep it with me in a variable).
- before I execute the update statement to update the specific record I check for the record timestamp and compare it with the timestamp variable,and if there's any changes I display message for user before saving.
* About updating data according to database changes (which occurred by other users) till now I have two choices,
-first one is timer and I dislike
-this idea,the second choice is Using SqlDependency for data change events
|
|
|
|
|
EgyptianRobot wrote: * About saving two records at same time I follow the following:
Concurrency-problems. What happens when two people edit the same record? Whose version is saved? Also keep in mind that the network-traffic and server-usage grows with the number of concurrent users.
No, I'm not going deep into the possible pitfalls; seen enough hacks that "proved" that the prototype works, but have yet to find the first real implementation.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Also keep in mind that the network-traffic and server-usage grows with the number of concurrent users.
You are right,do you think it's better to add a refresh button above the grid?
|
|
|
|
|
EgyptianRobot wrote: You are right,do you think it's better to add a refresh button above the grid?
Most people will recognize and know what to expect from a refresh-button. It's easy to implement, so yes, that'd be my preference.
Perhaps you could try a combination of both idea's, although I can't guarantee how it will do in practice; you could give the refresh-button a visual indication if there's "a change" (keeping track of the latest change requires one timestamp, is a lot more simpeler than keeping track of every record-modification)
The visual clue would indicate that there are changes, giving the user the option to refresh if required. That way the user would still be feeling "in control", and you wouldn't need to steal focus or move around updating the selections.
If you have the time, do experiment
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Perhaps you could try a combination of both idea's
Okay,till now this is the best solution and Thanks Million for this helpful ideas.
|
|
|
|
|
My pleasure, glad I could help a bit
|
|
|
|
|
EgyptianRobot wrote: About saving two records at same time I follow the following
What business case drives your expectation that this is even possible?
What business case drives your expectation that if it did occur it would be a problem?
As an example, you have a customer screen and two users update the address field at the same time. Exactly what are the duties of the people who actually do these updates such that two of would be attempting to update the same customer at the same time? And if they did why would they be using different data?
|
|
|
|
|
I did not warn for concurrency problems on a business-case, but a technical reason. Why? Because it happens in practice; a manager "rectifying" an error in a record, while one of his worker is updating the same record. Whose values would the database be saving, and whose would be discarded?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Why? Because it happens in practice; a manager "rectifying" an error in a
record, while one of his worker is updating the same record.
Do you have a specific industry and specific type of record/field for that example?
Moreover what is the work flow? In a standard call center, which is the only one I can think of for that example, the worker is already on another case before the manager reviews the worker updates.
|
|
|
|
|
jschell wrote: Do you have a specific industry and specific type of record/field for that example?
Yes, multiple.
jschell wrote: Moreover what is the work flow? In a standard call center, which is the only one I can think of for that example, the worker is already on another case before the manager reviews the worker updates.
Not every software-shop take the time to analyze the workflow. Imagine a MDI-form with a huge switchboard made of Buttons. Each button represents a table and opens a grid. 40 users, approx 120 tables. Administration-package, homes for the elderly. A single record might look like this;
PrimaryKey SetDataBits
123 101011110010101000100001000001100101010000001 Another example?
Same kind of "architecture" (I don't come up with them), a VB6 application that shows "Buttons" on the start-screen. Tables again, with grids. Their "workflow" consisted out of arrows drawn between the buttons. "First this table, then edit that table". Over 200 concurrent users. They discovered parameterized queries last year.
Another example?
Someone doing a MAX on a table, while another part of the computer does an insert. No, of course it ain't wrapped in a transaction. Which part of the app? Well, the logger of course 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Yes, multiple.
Then provide a specific example.
Eddy Vluggen wrote: A single record might look like this;
No.
First can you provide a REAL example? I have written code for a call center, a doctors office and many apps for telephony and financial centers and have never come up with a real business use
Second your example seems to demonstrate, at best, a poorly written app. And then you derive the need from that. What I asked for was a business case. A business case describes the needs of the business (not technology) that requires that two users of the application will be working on the same data at the same time.
Eddy Vluggen wrote: Someone doing a MAX on a table, while another part of the computer does an insert
I don't understand what that has to do with what I said. Obviously that isn't two updates but rather a write and a query. And one can in fact decide to do it without locking based on the needs of the query.
|
|
|
|
|
jschell wrote: First can you provide a REAL example? I have written code for a call center, a doctors office and many apps for telephony and financial centers and have never come up with a real business use
I cannot think of one. Good point.
jschell wrote: I don't understand what that has to do with what I said.
Providing an example, which, in retrospect, is unrelated to the subject.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Yeah, what Eddy said. Plus Grids are horrible anyway -- not very user-friendly.
|
|
|
|
|
usually I use grid to show data only, and above the grid I have insert,update,delete buttons.I guess now it's user friendly,Isn't that?
|
|
|
|
|
Better create a server which talks to the database. And all your clients connect to the server. Because all changes have to go thru the server now, the server can generate appropriate events.
|
|
|
|
|
may you give example or link to sample, I feel your solution will be the best...
thanks in advance....
Actually I don't know what do you mean by createing a server
modified 28-Aug-12 3:37am.
|
|
|
|
|
The "server" s another application running on a different computer (I recommend to use the same machine as with the SQL server). That applciation is often a Windows service, without any user interface.
The client applications connect to that server. You can use e.g. .Net Remoting, or more modern WCF.
When you start learning these things, they may look complicated, and it may take some time to get familiar with the concepts. But it's worth learning.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
