"I want to implement Gridview custom paging with full text search, with each individual page being bound to only 10 results/records.
My current setup fetches all the search results (rows) on each button click but displays just 10, making it very resource intensive. If it is of any consequence, in my current pagination setup I have first, next, last and previous buttons beside the actual page numbers.
I would like to retain the same scheme but only have it fetch up to 10 results for each page and display as many at any given time.
Should I work on adapting this particular method:http://www.c-sharpcorner.com/UploadFile/99bb20/custom-paging-with-gridview-control-in-Asp-Net-4-5?
If yes, do you have any suggestions as to how i could go about doing so in my case? If not, please suggest some alternatives?"
To fetch all the data while populating the grid for the first time is not a correct approach I think.
Depending on the page number and number of data that needs to be fetched, you need to get only that data from the database by sending the page number and page size qith your query.
So, when you click on First, Next, Previous and Last you send the page number and page size and get the data from database by calculating the total number of records.
Hope this provided you with an alternative approach.
Thanks!!
Related
I am a newbie in Infopath & Sharepoint. I am trying to create a form from Infopath 2013 and publish it as a document library to Sharepoint. I have some 60 fields that needs to be calculated(add) into another field. When tried to use the Design Checker, it throws an error as mentioned below in the screenshot. But it accepts if I key in only 45 fields in the Insert Formula text area. Is there any limitation on number of fields to be entered in Insert Formula? When I use PREVIEW in Infopath it works fine. This error pops up only when I try to publish it to Sharepoint. Any ideas on how to resolve this? - Thanks inadvance
InfoPath preview is rendered with IP Filler. The Browser experience has always been different, and the Filler preview is not a reliable check for the browser experience. You may have hit the limits of what a browser form can do. I don't have the numbers or limits, though.
Looking at the error message, you seem to be amassing an awful lot of calculations in one single field. My gut feeling is that this is very bad information architecture. What is the purpose of the form? What are you trying to achieve? Why would anyone have 60 fields in a form?
It looks as if you are summing a large number of cells. InfoPath is not a spreadsheet.
Use repeating tables to capture similar data. Then you can total the table entries with a standard IP function.
This looks like a sum of all the items a restaurant has on the menu. This is a perfect case for a repeating table. Don't use all 60 items on the menu in a list of 60 fields all in one form. That is overkill and not user-friendly. Create a repeating table structure where the user selects one of the 60 items and enters the transaction data. Each row of the repeating table can have another item of the list of 60. The grand total will be calculated from the entries.
If that is not viable, use helper fields to calculate sub totals by item category, and create a grand total from all the category totals.
There may be an easy answer to this and I just don't see it b/c I am too close to the project - so be it.
I have an asp.net 2.0 search application. It is a series of pages that start with a search form and end with the results being displayed to the user. Between the search and results page is a filter page that displays a series of filters the user can filter down the search results to. I execute the initial search on the search page and store the results in the session. If the initial search results total more than a certain number (let us say 50 for the sake of the example), the user is taken to the filters page. There they are presented with a number of filters they can apply to the results.
Once the selected filters have been applied to the search results, if the count is still more than 50 they stay on the page with only the filters they have not selected still displayed on the page. If the count is less than 50, they are taken to the results page. Now if they are on the filters page but wish to see the results, there is a button that takes the current state of the results and takes the user to the results page.
Here is my problem - if I am on the results page after applying some filters and click on the back button (none of the pages cache), how can i get the previous state of the search results BEFORE whatever filters I selected had been applied? Even further, if I got to the results page after a series of say 4 "apply filters" (apply filter - still over 50, apply other filter - still over 50, apply yet another filter - still over 50, and finally apply another filter - yay! under 50 go to results page), how do I get each version of the ever shrinking search results from the session if I keep hitting the back button?
Sorry if this is a bit weird and not that easy to understand - this is one of the problems that is not simple enough to just wrap it in a few simple sentences.
I am most eager for any thoughts (pertaining to the question at hand) or questions.
UPDATE -
FYI, I did not decide on the mult-page design. A requirement stated that it follow the flow of an existing third-party search app (reverse engineering is wonderful right?).
Thanks
Not to be too critical, but what you described sounds like a seriously jacked up way of handling search.
Typically, your search criteria and results are on the same page. When you modify the criteria and click search you should just display the top 50 results and let them know there are more. This can't be any more expensive an operation that what you've described because you have to run the queries under both circumstances anyway.
Take a look at NewEgg.com and try their "advanced search" from this page. You'll notice there are about 20 different criteria factors on the left. As you add a new criteria, the bread crumb at the top of the page changes. They have a little (x) next to each in the bread crumb so you can quickly eliminate any criteria from your search results. Voila no back button needed.
Note that at no point do you need session state to handle this. At most you could use hidden form fields which would still support back button usage in the browser, if they really wanted to.
Use your current session-based parameters as is, but let any querystring-parameter override them. This way you keep your values w/o assigning them to every url, yet adjusts to any previous manual data-enrty (querystrings in the browser-history).
(And don't use POST for search.)
I am making a page in asp.net using C# and my page consists of two drop down list one for state and one for subjects, both the data are coming from database, and there is a third database table for storing user details and the third table consists of name class and subject
Now my problem is that on click of search button i want to search the users table and return the value selected by person searching through drop down list on the master page and the result will be displayed on the next page
Please help as to what to do for search button, and what to write on second page on which i want to display the results.
Your help is badly needed
Thanks in advance.
This sounds like a homework assignment... Have you tried to solve this already on your own? What did you try, and what-if-any problems did you run into?
Here's one (of a thousand other) tutorials that will walk you through filtering a result page using a drop-down.
http://msdn.microsoft.com/en-us/library/aa581789.aspx
Good luck!
I have created a small "Dynamic Data Web Site" using the Entity Framework. I've no experience with this really, but it looks very interesting. Anyway, I have a single table being displayed on a single web page. The table contains over 21000 rows and the page limits me to 10 records per page, which is all fine.
My problem is that the page is incredibly slow. I'm guessing that maybe every row in the table is being loaded whenever I try to navigate, but I can't be sure this is the cause.
How can I increase the performance of the page? I want to be able to click through pages of results quickly and easily. It currently takes more than 60 seconds to click to the next set of results.
this is usually caused by filters on a table where the filter has MANY rows you could fix this using the Autocomplete filter which prefilters the data base what the user types in.
You can get this filter and other from ny NuGet package Dynamic Data Custom Filters
Also try having a look in it using Ayende's EFProf. It is a commercial product but it has a free 30 day trial. I can sometimes point out silly things you are doing and suggest some ways to optimise your data access
I've got a situation where I want the user to enter a start date and end date for report data. In addition there should be a drop down which allows the user to choose one of the following:
last 7 days
last 14 days
last 30 days
If the user selects one of these values, the datepickers should adjust there values? I can't quite figure out how to approach this. Anyone have any ideas.
This isn't possible solely from within SSRS. However, you can still achieve your goal with a bit of extra work. Here's a bit of pseudocode to get you going. This technique works and we use it in our organization often.
In SSRS, hide the report parameters
Create a new blank HTML/ASPX page
Using only HTML, create create your own datapickers and custom "last 7 days" dropdown.
Use Javascript/jQuery on the client to handle your custom logic.
Place a "Generate Report" button on the page.
Insert a hidden iFrame on the page
When the user clicks "Generate Report", perform an HTTP POST passing the report parameters in the URL (something like http://server/reportserver?/dir/Report&rs:Command=Render&Parm1=VALUE1&Parm1=VALUE2&Parm1=VALUE3)
Display the report in the iFrame
Your users won't know the difference and this will give you total control over the layout and presentation of your report parameters.
You can do this within in SSRS. Not great but acceptable.
Have the first parameter be a pick list with two choices.
Pick Dates or Last X Days.
Have the next parameter be the start date.
The third parameter is another pick list. It is either a list of dates or a list of numbers depending on the choice they made in the beginning.
Another way would be to have two reports displayed to the user. one with an open date range and one with a predefined pick list of dates. These would be linked reports that call the same underlying report but display different parameters. This is the approach I would take for such a user request.