|
http://www.obout.com/t2/eServerSideEvents.aspx[^]
I've used it, and it works well. They say it's the fastest on the market, but then, they would 
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
How deep are you going with your nodes? It's common to just retrieve nodes down to the next depth and then when expanding a node, get the nodes two layers down from that. This means that the user sees the nodes that can be expanded. Here's a quick example:
RootNode
|-Level 1
|-Level 2
|-Level 2
|-Level 2
|-Level 1
|-Level 2
Now, imagine that you are expanding the first Level 1 node, you retrieve the nodes below Level 2 so that the user sees the appropriate visual cues:
RootNode
|-Level 1
|-Level 2
|-Level 3
|-Level 3
|-Level 2
|-Level 2
|-Level 3
|-Level 3
|-Level 3
|-Level 1
|-Level 2
As you can see, you only get the information that you need so that you can keep the user happy. I hope that helps.
|
|
|
|
|
I have a gridview that displays about 2-50 records. While the stored procedure in SQL Query analyzer or the sqldatasource takes less than a couple seconds to run it takes forever for the gridview to display the data. At a difference instance I have tried to display the data with a repeater. It seems that there is no improvement. Has anybody experienced something like this?
|
|
|
|
|
What are you doing in the stored procedure to make it take several seconds to fetch so little data? I would expect at least less than 0.1 seconds.
Similarly, what are you doing with the gridview to make it take any time to display so little data?
Any code that you can show might help shed some light...
---
single minded; short sighted; long gone;
|
|
|
|
|
Well the stored procedure summarizes the sales for product(s) sold to customers for every month by salesman. The SQL is quiet complex and I do not think that this relevant though. It just passes back 27 columns"
Shipping company, Curent Year Sales By Month(12 columns), Total, Last Year Sales By Month(12 columns), Total.
But the rest of the code I think that is pretty straight forward:
SqlDataSource1.SelectParameters.Clear();
SqlDataSource1.SelectParameters.Add("Year", year.ToString());
SqlDataSource1.SelectParameters.Add("Prod", prod.ToString().Trim());
SqlDataSource1.SelectParameters.Add("Salesman", salesman.ToString());
SqlDataSource1.DataBind();
GridView1.DataSource = SqlDataSource1;
GridView1.DataBind();
It is the Gridview1.DataBind() that takes forever. The SQL profiler shows that the stored procedure(s) have been executed.
|
|
|
|
|
Is the SqlDataSource1.DataBind() necessary? Is the stored proc being executed twice by any chance?
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
No is not necessary. The stored procedure is not executed twice. I wonder if in IIS there is a limit on the page size.
|
|
|
|
|
VickyC# wrote: I wonder if in IIS there is a limit on the page size
Are you running your web app and database on the same machine or are you fetching the data over the network? Since your stored proc is only pulling out 27 records, it shouldn't be close to any page size limit.
How quick does the stored proc run by itself when shot through query analyzer?
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
No they are on different machines. It is 27 columns 2-50 rows. But this is a part of a fairly sizable page. The stored procedure in SQL Query analyzer takes less than 2 seconds in the worst case.
|
|
|
|
|
It has a performance index of .69.
|
|
|
|
|
Since it is only 27 columns with 2-50 rows, that shouldn't be very heavy weight at all.
If you don't mind me asking, what are the other things going on in the page since you say it is a fairly sizable page?
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
There are just similar queries that provide sales analysis and forecasting. 9 gridviews 2 dropdown list boxes, 7 radio buttons, 1 textbox, 1 button, 8 sqldatasources. The total size of the aspx is about 189k. But at any given time only a few of these are activated.
|
|
|
|
|
How many of these other features of the page are running along side with the stored proc in question? Are the other gridviews, dropdowns, and 8 datasources active when you run the stored proc? Sounds like a pretty heavy duty page. Just trying to visualize it  Not sure of how much more assistance I can be, but there must be some silly thing going on here. I'd just look through everything and see what is bottlenecking your page. Even with all the features you mention, it should be within reasonable bounds.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
It is a heavy duty page but as you say is just a silly thing.
1. At any given time only a single selection is done
2. Just pass parameters to an sql data source.
3. The stored procedure(s) do the work.
4. Analyze/format/populate the data into a grid view.
5. Trigger via the selection item of the main grid 2 more detailed grid views. The process is repeated for the detailed gridviews.
Sometimes there is no page expiration. But then some times when larger datasets are called then for sure there will be a page timeout. It all way though happens on the gridview databind. The larger datasets are not that large (50 recs vs 2). The underlying data of the stored procedure contain lot of data. But how could this be relevant?
On stand alone page there is no issue. But I would hate to separate the gridviews since they provide an nice concise presentation.
|
|
|
|
|
VickyC# wrote: The underlying data of the stored procedure contain lot of data. But how could this be relevant?
It shouldn't.
VickyC# wrote: I would hate to separate the gridviews since they provide an nice concise presentation.
I wouldn't. Most sales people I've ever run into, like the big picture. Do you have any code profilers to use? You may want to look at execution paths of your code...
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
I appreciate your support. I just need to hit the sack. It has been a long day.
|
|
|
|
|
VickyC# wrote: I just need to hit the sack. It has been a long day.
That is a good debugging tool, the pillow  Maybe tomorrow it'll stand out what is causing the timeouts
Have you tried to increase the timeout for both IIS and the database?
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
FYI. My method just worked. May be you should follow it.
|
|
|
|
|
Hey VickyC#,
Good morning and what was your method I should follow?
Paul
"You will see a delete button on each of your posts. Press it." - Colin Angus Mackay
|
|
|
|
|
I wasn't sure where to put this dilemma, but here it goes.
I have a web application wrapped around a state machine workflow that allows the user to pick search parameters from one content pane and then displays the results in the parallel pand via a gridview. I've wrapped both panes in <asp:updatepanels> and am using ajax extenders (Calendars and Watermark) in the search pane. I also have the search parameters saved into a Dictionary object.
Unfortunately this is slowing down this portion of the application to a crawl. I'm at a loss as to what is causeing the delays, which happen both on ititial page load and when search button is clicked. I'm using some ajax extenders in other portions of the application with no detriment. I would provide code samples if you think they'll help, just ask
Any suggestions or leads would be much appreciated.
Thanks,
An American football fan -
Go Seahawks!
Lil Turtle
|
|
|
|
|
Have you tried doing this (as a test) outside of any kind of Ajax framework? That might help you identify where the bottleneck is. How much data are you trying to load at page load/button click? Where are you getting this data from (for the search parameters & results)?
I think chances are that the problem lies in where you're getting your data from.
I think I'm going to call my next project "Chuck Norris". It's a sure way to guarantee it's unbreakable.
• • •
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
|
|
|
|
|
Dave Sexton wrote: Have you tried doing this (as a test) outside of any kind of Ajax framework?
I have, it's only about 40 - 45 K being transferred.
Dave Sexton wrote: the problem lies in where you're getting your data
I think you may be right.
Gratzi,
An American football fan -
Go Seahawks!
Lil Turtle
|
|
|
|
|
Ok, so where are you getting your data from?
I think I'm going to call my next project "Chuck Norris". It's a sure way to guarantee it's unbreakable.
• • •
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
|
|
|
|
|
SQL server Database, using Net Tiers and also MS Workflow.
An American football fan -
Go Seahawks!
Lil Turtle
|
|
|
|
|
I can't remember which property of the UpdatePanel that caused me to slow down a while back. I think it was ChildrenAsTriggers. Play around with the few properties it has as it turned out to significantly reduce the amount of time it displays. Also, try not to use the DataBoundEvent if possible. You can tweak most of column properties from the eval & '<%# ... %>' code. I found it is faster to use IIF statements with in the '<%# ... %>' than the code behind event.
Michael
I firmly believe that any man's finest hour, the greatest fulfillment of all that he holds dear, is that moment when he has worked his heart out in a good cause and lies exhausted on the field of battle - victorious.
Vince Lombardi (1913-1970)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
