Develop Reference

Retrieving large datasets using RIA services

We are planning to develop a charting application based on Silverlight(using infragistics xamdatagrid). The application will be very much like Google Finance like charting tool with an ability to view historical data. We have a master table that has stock indicies and a bunch of other parameters for the last 20-25 years.
Is it wise to use RIA services to retrieve the data and render the data charts on a silverlight application? Also please note that the master table in the database may be subject to many changes(addition or removal of columns) and we would not like to always update the service/webapp to reflect the changes and therefore needed the design to be generic.

Hope not too much late, anyway I hope this answer could help others. I recommend for this scenario create a Data Warehouse to make the queries to create the charts against it and not against the real active and frequently changing source database.

Data Application based on OO Concepts

I'm looking for an application developed in C# with following qualities, which is available as source code.
Based on OO Architecture
Must connect to DB.
Must handle atleast a "one to many master child" relationship (eg: Order and items ordered)
Should display the data using Datagrid or other similar controls.
Reports (either with report viewer or otherwise)
I want to understand the layering of objects better. Could you please help by providing some links.

This is very basic. Try code project or some good books:
http://www.codeproject.com/

Datagrid doesn't refresh on changed data

Is there any way to have a datagrid listen to the database and automatically update the data if the database data is changed? I use a SQL Server database.
I'd like to use Linq-2-SQL if possible

Because #Slaggg asked: there are fairly straightforward ways of doing this, but they're almost certainly going to involve a lot of coding, it'll impact performance pretty significantly, and my strong suspicion is that it'll be more trouble than it's worth.
That said, for a typical n-tier application, at a very high level you'll need:
(1) A way to notify the middle tier when the data changes. You could use custom-code triggers inside each the table that fire off some sort of notification (perhaps using WCF and CLR stored procedures), or you could use a SqlDependency object. Probably the second would work better.
(2) A way to notify each client connected to that middle tier. Assuming that you're using WCF, you'll need to use one of the duplex bindings that are available, such as Net.TCP or HttpPollingDuplex (for Silverlight). You'll need to make sure this is configured correctly on both the client and the server. You'll also need to manually keep track of which clients might be interested in the update, so that you can know which ones to update, and you'll need to be able to remove them from that list when they go away or timeout. Tomek, from the MS WCF team, has some pretty good examples on his blog that you might want to investigate.
(3) A mechanism to update the local client's model and/or viewmodel and/or UI once you get the notification from the middle tier that something has changed. This is more complicated than you'd think: it's difficult enough to keep your UI in sync with your data model under normal circumstances, but it gets dramatically more complicated when that data model can be changing under you from the other direction as well.
The idea behind these sorts of notifications is straightforward enough: but getting all the details right is likely to keep you debugging way into the night. And the guy who has to support all this two years from now will curse your name.
Hope this helps.

It depends from where you are updating the database:
From the same context (in
Silverlight, are you adding,
deleting, editing on the same page)
From a ChildWindow in your
Silverlight application
From an
external, non-related tool, outside
of your Silverlight application

OOP and DataTables for Rank Amateurs

I'm a total amateur writing a small App to track to changes in folders. I imagine I'll be keeping information about the directories to watch in one datatable bound to a gridview, when the user clicks a button, the program will create FileSystemWatchers to keep an eye on the directories and they will send their event messages to another datatable bound to another gridview. Where in the wide wide world of OOP should I be declaring, initiating, and manipulating the Datatables? The main form, inside main, in a class, or should I "give up" and use Visual Studio to automagically create a DataSet and stick two tables in it?

Well horses for courses. For a little utility app you would probably be better off using the VS "Visual/RAD" style of programming. Eg drag and drop tables etc on to the form, like most of the tutorials show.
Strictly speaking, and for a larger app, a more correct way would be to make a separate assembly(.dll) that handles data access and you call the classes within that assembly from the main form. This concept goes under a number of terms, but effectively you want to separate your concerns. In other words, let the UI handle UI interactions, have a separate assembly/project/whatever that handles database interactivity, and another separate assembly/project/whatever that handles business logic etc.
That last couple of sentences can mean different things to different people, and there is no 100% correct way to do things.
Some articles that may help:
link text
link text
link text

I agree with KiwiBastard: you get quite a bit of benefit from using the VS tools to generate a typed DataSet.
That just generates classes, though. You still have to manage an instance of the DataSet. For a very simple app, where I haven't factored UI and business logic into different classes, I'd do that in the Form. For an app of any complexity, it's part of the business logic class.
Something that will probably save you a lot of trouble: data binding is good, ADO is good, but certain kinds of ADO code (in particular event handlers on the DataTable) do not play well with data binding. If you're using BindingSources (and, really, you should be), it's generally a good idea to suspend binding whenever you're manipulating the DataSet's objects programmatically (like, when you're adding and deleting rows). The cost of suspending and resuming binding is very small, and it eliminates an entire class of problems that are extremely hard to diagnose.

What is the best control to use to display items from a database?

I'm writing a website that will sell items from one of my classes. It will be linked to a SQL Server db where I will pull pricing, item name, quantity and description. If I wanted to display the items from the database in a thinkgeek fashion, what would be the best control to use so I can custimize the display to actually look ok?

You'll get the best flexibility with an asp:Repeater. This means you'll have to program more, but it will give you more flexibility.

Not sure if you have any technology requirements, but the ASP.Net has a new type of ASP.NET project called the Dynamic Data project. Using that project you can point to your SQL Server and generate pages to display and edit the data. Pretty easy to get up and running quickly using that.

I'm a fan of the ASP.NET GridView & DataGrid, throw in some template fields for your images and links and what not.

#rslite and #Bryant both have good suggestions. My initial go of the problem would probably involve creating a "Thinkgeek-esque" user control, and plopping that into a repeater for display. However, the DDP would be a good call as well. Really depends on deeper level requirements than you mention.