January 29, 2010 at 5:07 pm
Comments posted to this topic are about the item usp_TransposeNRows v2.0
February 17, 2010 at 2:44 am
Hi, thanx for the contribution, this sounds good...
There are still some problems though, try following:
create table dbo.Something(
ID int identity(1,1) not null,
NVarCharValue nvarchar(50) null,
DateTimeValue datetime null
)
go
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('1', null)
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('2', null)
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('71111111111', null)
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('abc', null)
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('xxxx', getdate())
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('yyy', null)
insert into dbo.Something (NVarCharValue, DateTimeValue) values ('zzz', null)
go
select * from dbo.Something
exec dbo.usp_TransposeNRows 'Something',10
I will try to analyse where the problem is...
Cheers, Richard.
February 17, 2010 at 6:23 am
Richard,
Thanks for your test case, and for offering to look into the issue.
I've done a quick check - the problem appears to be with the NULL values.
I'll dig further and post a fix soon.
Jeff
September 10, 2014 at 5:22 am
Is this a personal preference to browse the data in this fashion? Are there particular cases (types of data, I guess) where you've found this to be advantageous?
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 10, 2014 at 6:58 pm
Great stuff. As to why transpose, here is an OLTP example.
True transpose is useful to simplify several patterns. My fav was a test specification system where new tests came an went at technician's whims. The tests were in an ever changing list. Data needed to be captured in a grid, so test names transposed to columns and instances of results became rows. But storing results needed to be a row with test name and value. So spec transposed to result grid which transposed to the saved data. Oh, and the tests were in sets.
Easy in an array language, not so easy in relational. Arrays have implied axis that are not part of the array per se. Each position can be named, like an enum. In relational, the column axis is part of the meta. They are essentially enum named positions. Rows are ignored in the meta, which is correct as far as relational theory goes. In practice auto-identity and row_number() show up a lot, implying array like processing is desirable. Rows have business keys or surrogate keys or occasionally none at all. Row keys are akin to column names and like column names can be paired with positions. That is the key is an enum for a position.
By analogy, just like meta data for columns, meta data for rows makes sense. In the test specification system, we took advantage of row meta by naming the row positions as a composite of business keys. That simplified code. The row meta can be just a table 1-to-1 with rows of the original.
Having column and row meta data opens up emulating array transposes. That is (row, col) becomes (col,row). Perhaps some clever guy has or can make a fast way to use that fact to perform a transpose.
The ideal transpose will recreate the original when transposed back.
We also used dynamic sql, but without while loops. SQL imposed a column limit, thus a row limit, at the time I believe it was 1024 columns. It might be worthwhile to dynamically create an inline table valued function simply because Insert-Exec is so inelegant.
May 19, 2016 at 1:16 pm
Thanks for the script.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply