View Complete Post
MSDN Magazine October 2004
First time post here, if i'm in the wrong area please move as necessary. Thanks
I'm using VWD with a database back end. I have a list of teams which are marked off by league, level, division, teamid and then using gridview for the list of players per teams.
I've got the drop downs working correctly but running into a little snag and that is on the auto postback.
When I only have one option come up in a list, i obviously don't change that list and thus it doesn't change the next drop down because there is no post back. is there a way to use a "header" value?
Example of my data
League Level Division Team
NHL 1 West VancouverNHL 1 West CalgaryNHL 1 West EdmontonNHL 1 Central Chicago
OHL 2 West LondonOHL 2 West Guelph
NBA 1 Central ChicagoNBA 1 Central DetroitNBA 1 Central Milwaukee
So my drop downs choose by league, then level then division and then team then shows the player roster for that selected team.
The problem I run into is when only one value exists based on the previous choices I've made. If I choose NHL then Central only Chicago shows up in the example above. Because I'm not choosing between it and another value, the drop down does not put in a post back and thus I don't get a list of the team and then the players
In the ETL design we have followed drop index before data load and recreate it after load. But looks like this approach is time consuming.
Is there any better data load design approach? Will table partition solve this problem?
In our scenario, subscriber and publishers have same tables and we want the indexes also to be same at all places..
How to auto create (or Generate a script) which can create indexes on subscriber which are already added on publisher.. Is there a auto way or is there any article somewhere which can help..
I am trying to convert a stored procedure to a table valued function and the performance has taken a HUGE hit and I was wondering if there was anything that can be done about it. Since a table valued function can not use #temp tables it must be converted
to a @temp table variable.
Here are some steps I have already taken...
The original stored proc starts off by populating a #temp table via "Select x Into #temp ..."
Leaving it a stored proc for now, I explicitly created the #temp table and did an "Insert Into ... Select From" to more closely model how it must work when using a @temp table variable. There was no discernible performance difference.
Still leaving it as a stored proc, I then swapped out the #temp table with the @temp table variable and now, all of the sudden, the performance drops from sub-second to over a minute!!!
The temp table only has one field defined as an int and it is distinct, so I tried making the field the Primary Key to see if that would help and it did not.
The temp table is created by scanning a table with around 11,000 rows and the temp table itself has about 4400 rows in it (if it makes a difference to anyone).
Does anyone have any suggestions (or hope) for me?
Hello, we are currently doing some performance tests for our WCF services running on IIS 7. Performance is as expected with moderate CPU and memory usage (CPU usage less than 40%). We are facing a problem when IIS recycles a worker process: After the recycle
the throughput drops by about 1/2 with multiple times longer response times.
Some details about the setup:
How much can affect the performance heavily loaded sql-server intensive use of such tools as SQL Server Profiler ?
I have a performance issue when trying to update a table with multiple indexes. The table itself has about 280 million rows. The selection of the records is fast, about 160 ms, as it has a suitable non-clustered index. However the update itself takes over
When I look at the excution plan, it shows the update to the clustered index as well 5 other non clustered index which are being affected by the statement. Unfortunately it doesn't show me how those indexes are being accessed. I suspect that the update statement
is performing a full index scan against each of the non-clustered indexes in order to do the update.
So my question is this, if i add the key columns of the other non-clustered indexes as included columns on the index used to select the records for update will sqlserver use them to access the additional non-clustered indexes?
any advice greatly appreciated