StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You are looking for the "best approach on finding rows in a datatable", so I first have to ask: "best" for what? I think, any technique has scenarios where it might fit better then the others.</p> <p>First, let's look at <code>DataView.RowFilter</code>: A DataView has some advantages in Data Binding. Its very view-oriented so it has powerful sorting, filtering or searching features, but creates some overhead and is not optimized for performance. I would choose the <code>DataView.RowFilter</code> for smaller recordsets and/or where you take advantage of the other features (like, a direct data binding to the view).</p> <p>Most facts about the DataView, which you can read in older posts, still apply.</p> <p>Second, you should prefer <code>DataTable.Rows.Find</code> over <code>DataTable.Select</code> if you want just a single hit. Why? DataTable.Rows.Find returns only a single row. Essentially, when you specify the primary key, a binary tree is created. This has some overhead associated with it, but tremendously speeds up the retrieval.</p> <p><code>DataTable.Select</code> is slower, but can come very handy if you have multiple criteria and don't care about indexed or unindexed rows: It can find basically everything but is not optimized for performance. Essentially, DataTable.Select has to walk the entire table and compare every record to the criteria that you passed in.</p> <p>I hope you find this little overview helpful.</p> <p>I'd suggest to take a look at <strong><a href="http://msdn.microsoft.com/en-us/library/dd364983.aspx" rel="noreferrer">this article</a></strong>, it was helpful for me regarding performance questions. This post contains some quotes from it.</p> <p><strong>A little UPDATE:</strong> By the way, this might seem a little out of scope of your question, but its nearly always the fastest solution to do the filtering and searching on the backend. If you want the simplicity and have an <strong>SQL Server</strong> as backend and .NET3+ on client, go for LINQ-to-SQL. Searching Linq objects is very comfortable and creates queries which are performed on server side. While LINQ-to-Objects is also a very comfortable but also slower technique. In case you didn't know already....</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload