CODEWITHSUNDEEP
c#sqlwpfbigdata
user1021726
user1021726

Reputation: 648

loading a lot of data into WPF datagrid

I have 4 sql queries that fetches a decent amount of data, where 2 of them take about 30 and 60 seconds respectively.

I intend to cache a lot of the data so after the initial load it won't take that long...

However the initial load will still take a lot of time so I'm just wondering What's the best way to fetch and load these 4 datatables from SQL Server into 4 individual WPF datagrids?

I don't think there is much to be gained performance-wise from the sql query itself. They are pretty straightforward selects but the bottleneck is a JOIN on a linked server on another network.

Is it simply a matter of asynchronously running each query and loading them, or is there a better approach?

Upvotes: 0

Views: 1297

Answers (3)

Dean Kuga
Dean Kuga

Reputation: 12131

Use Task Parallel Library when you call the method that fetches the data from the database and that operation will be performed on a separate thread created by the TPL...

using System.Threading.Tasks;
...
Task.Factory.StartNew(() => GetLotsOfRecordsFromDB()).
            ContinueWith(t => ...);

Use TaskScheduler.FromCurrentSynchronizationContext() in ContinueWith if you need to access the UI thread.

That is by far the simplest, least verbose way of doing it...

Upvotes: 1

paparazzo
paparazzo

Reputation: 45106

In the get you could run query asynch
That is probably the most efficient approach

You many want to look at priority binding
PriorityBinding

Another option is to use a BackgroundWorker to retrieve the DataTable in the backgound.
BackgroundWorker
As for 4 DataTables you have a few choices.
You can fire them all off at once.
Or you can fire the next in the complete event of the prior.

Upvotes: 1

Craig Graham
Craig Graham

Reputation: 1191

To formalise it; your bottleneck is in the backend design and nothing to do with the frontend application. Change the backend design so your app no longer requires the join between servers each time an instance of the app starts up. This could be a simple executable running periodically on the database server and maintaining a cache table that your frontend retrieves in one hit, or it could be a full service that your app accesses the database through.

Further, since the data only updates every 24 hours- and is still probably a sizeable chunk to be shifting about- maintain a local cache on each end user machine that's only refreshed if it is older than the last central version of the data.

Upvotes: 1

Related Questions