Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/plarsson/pivottableformicrosoftsqlserver.asp
Very nice! I will probably use this at some time. Thanks heaps!
Have you considered building the update string inside the loop, but executing it after you have iterated all the columns? O(1) < O(n)
Also, do you have any comments/caveats on the security implication of dynamic SQL used in this process?
Thanks Peter - nice looking article.
I've not read the whole article yet (that's for when I have more time), but I wonder how your approach compares with the 'classic' crosstab/pivot table approaches...
If anyone has time to evaluate this, I'd be very grateful!
Solutions are easy. Understanding the problem, now, that's the hard part.
Yes, in my very first early version. Then I realized that I could potentially come across the 8000 character limit for varchars.
I have tried to keep the dynamic SQL executions to a minimum for obvious speed reasons. What I think I have provided is a base for creating crosstabs/pivots for users to learn from and hopefully, evolve with.
There are some things to do with the code to make it "universal". But I thought it would be best to show how to start from the beginning.
To make the code "universal" you first have to build a dynamic query for preaggregating the data in #Aggregates. That is not very hard to to! Also, you must change the parameters to the future stored procedure to allow two fully qualified names such as RemoteServer1.OwnerLocal.ThatTable.ThisField for the rows and columns. Even the CellData field in #Aggregates could be taken from a parameter this way and called with 'SUM(x)' or 'COUNT(y)'. You catch my drift.
An example could be
EXEC dbo.CrossTabPivot 'Table1.OfficeName', 'Table2.Category', 'COUNT(t)', ...
Yes, SQL injection could possible be an issue here, if the data in ColumnText is written such way.
But since the beginning of the UPDATE-statement is hardwired with "UPDATE", I right now can't see a way to manipulate the statement to run SQL injection code.
I think it is worth mentioning the restrictions of that method such as:
- MAX number of columns (?),
- MAX total row length (8K).
I've used similar method using cursor instead of column table.
Perfect timing! I was able to use this logic for a report today. It made short work out of an otherwise arduous task.
Max number of columns are restricted to what datatype you use for #Aggregate column. The total size for a row is 8,060 bytes. Using 60 bytes for RowText leaves us 8,000 bytes for the rest of the columns and since INT is 4 bytes, we can potentially have 2,000 columns. If you prefer SMALLINT (2 bytes) as #Aggregate column, you could theoretically have 4,000 columns.
Now I have to look up "arduous" in my dictionary...
Thanks Peter. It is very good procedure and I shall use it.
R. M. Joseph
You are welcome!
I am satisfied you liked the article. I really struggled to keep it simple and consise. And as you write, my purpose was to give away the base of what pivot tables really are.
I now need to somehow work out to add ordering based on these "unknown" columns but this is a great start to stuff I really did not understand.
A Huge help - thanks.
Viewing 15 posts - 1 through 15 (of 43 total)