I have no experience building a .NET desktop application, all my experience is with the web. A friend of mine has asked me to do a quick estimate for a small desktop application.
The application just displays a list of items from the database. When rows are deleted/added from the database, they need to be deleted/added from the list on the user's desktop.
Is this done pretty easily in a desktop application, or do I need to do any sort of "reload" every X seconds?
The simplest design would involve polling the database every so often to look for new records. Adjust the number of seconds between polling to best reflect the appearance of real time and also for performance.
Any design that would allow the database management system to broadcast updates to a desktop application would be quite complicated and (depending on your needs) would most likely be overkill.
Elaborating on Andrew Hare's design slightly, I'd suggest that you include some sort of mechanism to 'short-circuit' the refresh cycle when user interaction occurs, i.e.
Refresh every x seconds AND Immediatey if the user clicks a control that is deemed to be a critical one AND the required update is less than x records EXCEPT where this would increase the refresh rate beyond a certain throttle value
Basically, you want to give the impression of high performance. Perceived performance doesn't mean accomplishing tasks quickly, it's more like doing the slow work during periods that you expect the user to be thinking, faffing around or typing something, rather than when they're waiting for a response. Very few applications are busy even a small fraction of the time they are running - any perceived slow performance is derived from a poor design where the program does too much work at once at the point the user asks for it, requiring them to wait. Caching in the background allows you to only assign the bare minimum amount of work to directly respond to user input, improving the user's perception of performance.
Trying to be directly helpful:
You state you're using .Net - which is handy. .Net databinding is very rich and powerful, and is quite likely to make this job a breeze.
However - read on...
There is a chance that it won't do exactly what you want. This is where databinding becomes a massive pain. Databinding requires certain things to be set up the way .Net wants it, and if they aren't, it's quite a lot of work reimplementing the basic functionality in the way you require. In this case, don't hesitate to reach for the MSDN documentation, and StackOverflow. Ask Early, Ask Often.