My DAL is created using Linq and all is fine. However, on one page, I'm to display a table (gridview) which pulls data from a SQL Server database table. However, I've heard many warnings about staying away from using any of the built in controls (ObjectDataSource and SQLDataSource). Is there any truth in this, regarding scalability/efficiency? I posted a similar problem before but, in this case, I have direct access to the server. What would be the best way to bind the data to gridview? I can't cache the data as is it tailored to individuals and I'd rather not store them in sessions as there could be between 100-200 custom objects being called. I haven't really dabbled in SQL, but with a bit of reading, I'm sure I could create my own custom server side paging/filtering/sorting. Would it be efficient if I created a stored procedure for each of these functions and called them from an objectdatasource, or should I call the SP using Linq to SQL (in my DAL) and then display that information directly to the gridview?
Thanks for any advice
There is nothing wrong in using a grid view, or custom object data source, if it is only for some hundreds of records. Scalability is an issue for thousands of records. Fastest Access possible would be via a DataReader filling a Datatable. Binding gridviews to a Datatable is always a good idea for a large number of records, as binding is fast and sorting also.
I have therefore written a library called modelshredder that can translate any IEnumerable collection of objects into a DataTable. It uses dynamically emitted code to do its Job, that's why it's fast enough for thousands of records. You can use plain linq-to-sql to write and execute your query, prefetably project into an annonymous type and call .ToDataTable() on the result.
Related
I have a handful of records, 5-10, that I need to take from the user and run a SQL merge statement against. I can think of three ways of accomplishing this.
.net Loop processing one record at a time - Wondering what the performance of this would be compared to the other options. I would think it is pretty good given connection pooling?
SQL Data Table type - I have seen these used elsewhere in the project, but as I learned first hand these are a pain to update the table definitions if need, dropping the entire object and recreating
XML variable - I have used this in the past. I like it because it is flexible to change the definition of the object. The .net is simple with XMLSerializer. But I am sure there is probably a performance hit to call XMLSerializer. And then on the SQL side to use the .nodes() function.
Does anyone know by personal experience or some reference, such as a white paper, which method is the most efficient when inserting/updating records in a database via .net application?
For 5-10 items you can use "clasic" insert with more records.
INSERT INTO MyTable
(ColumnA, ColumnB, ColumnC)
VALUES
(#ColumnA_0, #ColumnB_0, #ColumnC_0),
(#ColumnA_1, #ColumnB_1, #ColumnC_1),
(#ColumnA_2, #ColumnB_2, #ColumnC_2)
This is MUCH faster than XML or DataTable. And is faster than isolated inserts in loop.
The limit for number of inserted records is 1000. If you want more, you need execute more statements.
I'm working on a web application, on one page I am inserting records in the database and I want to display the data in a GridView but on a diffrent page. How can I do this?
I know how to display records in a GridView, but I want to know if there are two web pages,
on one page provides the facility to insert the records and U want to display the records in the GridView bit on the second page.
While it is possible to retain the data being inserted without retrieving it from the database, I think it is better to save the data on the first page and retrieve it from the database on the second page.
You can do this by writing inline SQL or a stored procedure. One simple approach would be to pass the resultset into a DataTable and bind a GridView to that.
That does involve more work -- more code and more trips to the database. However, I think it is very useful when performing INSERTs that the web page is updated to display what actually got into the database. Sometimes, this is different from what the user thinks they entered, and they can see the problem immediately.
One question would be how to identify the data that has just been inserted. I can think of several ways to do that. One is to query for all records entered today by the person logged in (which is recorded in the CreatedBy and CreatedDate columns of the database tables). Sort the resultset in descending order of CreatedDate, so that the most recent entries appear at the top of the GridView. Another would be by assigning a batch number to the data entry and retrieving only the data in that batch.
If you really want to hang on to the data entry, you could put it into Session on the first page, and then retrieve it from Session for display on the second page.
Following along the lines of what DOK said, it's also a lot easier to validate data entered by your users in your business logic before you submit it to the database.
Secondly, users can change their minds about data on a webpage frequently. The data on the web could be in an partially-finished state or could have typos or errors in it. If someone else saw this data and believed that it needed to be completed, then you could end up with duplicated entries in the database that would then require reconciliation.
Honestly, your best bet is to use the Session object to hold temporary user data. The MSDN entry for the GridView RowEditing event contains some great source code for this approach. Whenever I have to use GridViews to handle data from the database, I mimic this.
In addition to handling problems with temporary data storage, you can compare the Session object to your database results to determine whether or not new rows have been inserted. This is somewhat costly as it involves overloading the Equals method (and GetHashCode as well, if you follow what Microsoft recommends) and using Equals to iterate over the two collections, comparing the properties of both objects, and determining which records are new based on records that don't exist in your Session object, but do exist in your database object.
It's also worth noting that this approach assumes that you don't delete data from your database, but set the status of a record in your database to "Deleted" -- if that's a boolean field or an sequence of codes you use to describe the state of rows in a table.
For typical examples I see of SqlDataSource, LinqDataSource...
EVERY example deal with how to make changes to a Customer table where the Gridview/RADgrid directly represents the customer..
But in my case I have stored procedure which show data from multiple tables and make changes to multiple tables so it seems I am not a candidate for uses declarative data sources?
Or can anyone point me to an example?
Why not? If you can define single data object which will be used as result from GetCustomer procedure and input to StoreCustomer procedure you can wrap calling these procedures into some class and use ObjectDataSource. Your ASP.NET application doesn't have to know nothing about internal storing of Customer in database. The only requirement is to have flat object = no 1:N or M:N related data.
Not sure how to word the question...
Basically, so far all my SQL stuff has been stored procedures and dumped into a gridview. The odd case where I had to perform an action based on a value (such as highlighting a row green if a certain value was true) were done as the gridview was rendering in one of the overrides.
Now however I have to do something far more complicated - pull three sets of data down, run a series of checks on all three and some date related checks and stuff, then populate a gridview with some of the items.
In logic terms, I want to run three queries, and store the lists of results (presumably in Lists?) then run some logic, then populate the gridview.
Specifically what I don't know how to do is:
Best way of pulling the data, and putting it into a List or other datastructure that lets me easily run through it, and retrieve data based on column (myList.age, or more likely, myList["Age"]).
One I have compared the data, I assume I create a new list that will be put into the gridview... how do I put the contents of a list INTO a gridview? How would I add other stuff such as buttons or checkboxes at the same time?
Any nudge in the right direction would be appreciated! Particularly doing cool stuff with lists and sql (if there is anything cool you can do with them)
There are actually several ways to do this with .Net without using an ORM solution. Instead trying to list all of them here I will link you to an article series that should help you accomplish what you want. The following series of articles is about N-Layer design, and includes answers to the information you are looking for. The first set of 4 articles were created some time ago with ASP.Net 2.0 then the author updated them with an additional six articles using ASP.Net 3.5
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=476
If you want to avoid having to write SQL query and concentrate on the data instead, go with the Entity Framework. It's quite well integrated with VS. It will connect to your SQL database, you will tell it which tables to import, and it will create a series of classes for you to talk to your database.
Queries are quite easy to do, and they will return lists of objects which should be easy to manipulate and put to a grid later on.
You can create datatables and populate them using the lists that you have generated and then bind your grid using the newly created tables as the datasource.
I don't know when to add to a dataset a tableadapter or a query from toolbox. Does it make any difference?
I also dont know where to create instances of the adapters.
Should I do it in the Page_Load?
Should I just do it when I'm going to use it?
Am I opening a new connection when I create a new instance?
This doesn't seem very important, but every time I create a query a little voice on my brain asks me these questions.
Should I just do it when I'm going to use it?
I would recommend that you only retrieve the data when you are going to use it. If you are not going to need it, there is no reason to waste resources by retrieving it in Page_Load. If you are going to need it multiple times throughout the page load, consider saving the query results to a private variable or collection so that the same data can be reused multiple times throughout the page load.
Am I opening a new connection when I create a new instance?
Asp.net handles connection pooling, and opens and closes connections in an efficient way. You shouldn't have to worry about this.
One other thing to consider from a performance perspective is to avoid using Datasets and TableAdapters. In many cases, they add extra overhead into data retrieval that does not exist when using Linq to Sql, Stored Procedures or DataReaders.