page timesout
-
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?
-
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;
-
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.
-
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
-
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
-
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.
-
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.
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
-
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.
-
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 :-D 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
-
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 :-D 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.
-
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
-
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
-
VickyC# wrote:
I just need to hit the sack. It has been a long day.
That is a good debugging tool, the pillow :laugh: Maybe tomorrow it'll stand out what is causing the timeouts :-D 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
-
VickyC# wrote:
I just need to hit the sack. It has been a long day.
That is a good debugging tool, the pillow :laugh: Maybe tomorrow it'll stand out what is causing the timeouts :-D 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
-
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