<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Calculated Member as Regular Measure	</title>
	<atom:link href="https://prologika.com/calculated-member-as-regular-measure/feed/" rel="self" type="application/rss+xml" />
	<link>https://prologika.com/calculated-member-as-regular-measure/</link>
	<description>Business Intelligence Consulting and Training in Atlanta</description>
	<lastBuildDate>Wed, 17 Feb 2016 11:51:12 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: furmangg		</title>
		<link>https://prologika.com/calculated-member-as-regular-measure/#comment-80</link>

		<dc:creator><![CDATA[furmangg]]></dc:creator>
		<pubDate>Mon, 03 Dec 2007 17:16:29 +0000</pubDate>
		<guid isPermaLink="false">/CS/blogs/blog/archive/2007/03/04/calculated-member-as-regular-measure.aspx#comment-80</guid>

					<description><![CDATA[Yes, that &quot;10% performance penalty&quot; was tested on SP2.

By the way, I also discovered that doing a cast in the DSV is unnecessary. Just right click on the measure, choose Properties, expand Source, then change the DataType appropriately. Most of my research on this subject got worked into the following BIDS Helper feature:

http://www.codeplex.com/bidshelper/Wiki/View.aspx?title=Measure%20Group%20Health%20Check]]></description>
			<content:encoded><![CDATA[<p>Yes, that &#8220;10% performance penalty&#8221; was tested on SP2.</p>
<p>By the way, I also discovered that doing a cast in the DSV is unnecessary. Just right click on the measure, choose Properties, expand Source, then change the DataType appropriately. Most of my research on this subject got worked into the following BIDS Helper feature:</p>
<p><a href="http://www.codeplex.com/bidshelper/Wiki/View.aspx?title=Measure%20Group%20Health%20Check" rel="nofollow ugc">http://www.codeplex.com/bidshelper/Wiki/View.aspx?title=Measure%20Group%20Health%20Check</a></p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: tlachev		</title>
		<link>https://prologika.com/calculated-member-as-regular-measure/#comment-79</link>

		<dc:creator><![CDATA[tlachev]]></dc:creator>
		<pubDate>Mon, 05 Mar 2007 23:00:46 +0000</pubDate>
		<guid isPermaLink="false">/CS/blogs/blog/archive/2007/03/04/calculated-member-as-regular-measure.aspx#comment-79</guid>

					<description><![CDATA[Good point. Did you evaluate the performance impact before SQL Server 2005 SP2?]]></description>
			<content:encoded><![CDATA[<p>Good point. Did you evaluate the performance impact before SQL Server 2005 SP2?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: furmangg		</title>
		<link>https://prologika.com/calculated-member-as-regular-measure/#comment-78</link>

		<dc:creator><![CDATA[furmangg]]></dc:creator>
		<pubDate>Mon, 05 Mar 2007 16:29:12 +0000</pubDate>
		<guid isPermaLink="false">/CS/blogs/blog/archive/2007/03/04/calculated-member-as-regular-measure.aspx#comment-78</guid>

					<description><![CDATA[Two comments... I think you can get around the int issue by making your DSV named calculation be:
cast(null as decimal(20,2))

Also, in one cube I&#039;ve worked on, we had to make this very decision in deciding whether to make the placeholder for assignments physical or calculated. It appeared that there was a 10% performance penalty if the measure was physical when the calc script is doing a bunch of leaf level assignments. (We theorized that the reason for this was that the calc script was aggregating after the assignments, but I can&#039;t prove that.) In our case, we weren&#039;t interested in those assignment aggregating, so there was no point in making the calculated measure physical. Just wanted to mention that it&#039;s worth checking the performance of both alternatives.]]></description>
			<content:encoded><![CDATA[<p>Two comments&#8230; I think you can get around the int issue by making your DSV named calculation be:<br />
cast(null as decimal(20,2))</p>
<p>Also, in one cube I&#8217;ve worked on, we had to make this very decision in deciding whether to make the placeholder for assignments physical or calculated. It appeared that there was a 10% performance penalty if the measure was physical when the calc script is doing a bunch of leaf level assignments. (We theorized that the reason for this was that the calc script was aggregating after the assignments, but I can&#8217;t prove that.) In our case, we weren&#8217;t interested in those assignment aggregating, so there was no point in making the calculated measure physical. Just wanted to mention that it&#8217;s worth checking the performance of both alternatives.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
