http://www.sqlmag.com/authors/author/author/5055823/rsscomment/5055823en-USFri, 25 May 2012 10:36:01 GMTFri, 25 May 2012 10:36:01 GMThttp://www.sqlmag.com/article/sql-server/common-language-runtime-from-the-dba-point-of-view#commentsAnchorThu, 09 Feb 2012 11:18:12 GMT
How to common language runtime http://vb.net-informations.com/framework/common_language_runtime.htm jonath]]>JonathThu, 09 Feb 2012 11:18:12 GMThttp://www.sqlmag.com/article/sql-server/common-language-runtime-from-the-dba-point-of-view#commentsAnchorhttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorTue, 19 Apr 2011 19:33:23 GMT
Peter, Sorry, I clicked the finish button by accident before I finished. there is not enough space in this article to cover the background necessary to make a discussion of grds and tesselation understandable to the intended audience. I chose to accept the default settings for the index. You are correct in thinking that we might have improved the performance of the spatial index by fine-tuning it. However, I don’t think it would have affected the final conclusion that the traditional indexes performed much better in this case. Regards, Kurt]]>ksurvanceTue, 19 Apr 2011 19:33:23 GMThttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorhttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorTue, 19 Apr 2011 19:21:40 GMT
Peter, We did not cover Geometry spatial types in this article at all, as I mentioned near the beginning of the article. Since this is an article on Simplified spatial data, I did not cover the complexities of tellelation]]>ksurvanceTue, 19 Apr 2011 19:21:40 GMThttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorhttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorTue, 19 Apr 2011 19:11:39 GMT
Bijnens, You are right. This must have happened when the page was set up. I looked at the listings files I sent with the article and the names are there. I am sorry for the problem and thanks for posting the xml that fixes the problem. Kurt]]>ksurvanceTue, 19 Apr 2011 19:11:39 GMThttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorhttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorFri, 01 Apr 2011 05:49:49 GMT
You didn’t provide column names for the last 3 columns of the xml file.
To make it work I altered the fmt file like this:






Please correct me if I’m wrong]]>BijnensFri, 01 Apr 2011 05:49:49 GMThttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorhttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorFri, 01 Apr 2011 05:21:48 GMT
I wonder why you do not mention SPATIAL INDEX [1] at all. It’s the best way to use in database on geometry columns. Comparing the performance of spatial index would be a valuable outcome. (Or maybe I’m just missing the point :)

[1] http://technet.microsoft.com/en-us/library/bb934196.aspx]]>PeterFri, 01 Apr 2011 05:21:48 GMThttp://www.sqlmag.com/article/project-plan-tsql-sql-server-2008-r2-78/database-development/simplifying-spatial-data#commentsAnchorhttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorTue, 05 Oct 2010 20:25:38 GMT
AMY,

that solution gets the same results but relies on data that you won’t have in the real world, ie a correct height for each patient in the patientheight table. that table was an itermediate step in creating the sample data but does not figure in the solution.]]>SURVANCETue, 05 Oct 2010 20:25:38 GMThttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorhttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorThu, 30 Sep 2010 16:46:01 GMT
After populating the tables, I tried to write my own solution b4 looking at yours. I came up with:

SELECT ph.PatientID, ph.Height as BeginningHeight, VisitDate, pv.Height as ChangedHeight
FROM PatientHeight ph INNER JOIN PatientVisit pv
ON ph.PatientID=pv.PatientID
WHERE ph.Height <> pv.Height
Order by ph.PatientID

This actually seems to work better than the CTE solution. It would never have occurred to me to try a cursor solution. ]]>AmyThu, 30 Sep 2010 16:46:01 GMThttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorhttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorMon, 30 Aug 2010 16:38:05 GMT
the 19 in ABS(CHECKSUM(@i)) % 19 as well as the 7 in SET @i = @i + 7; are prime numbers that were used to make the selection of visitdates and patients psuedo random. It didn’t work out very random but it was enough for our test purposes.]]>SURVANCEMon, 30 Aug 2010 16:38:05 GMThttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorhttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchorThu, 19 Aug 2010 16:17:06 GMT
I don’t see why ’ABS(CHECKSUM(@i)) % 19’ was used in the UPDATE statement in Listing 1. Should it have been ’1 + ABS(CHECKSUM(@i)) % 19’ so that height changes would include all 20 dates and 19 possible date differences?]]>KehoeThu, 19 Aug 2010 16:17:06 GMThttp://www.sqlmag.com/article/sql-server/programming-sql-in-a-set-based-way#commentsAnchor