 




<?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: DFU to SQL translator</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/dfu-to-sql-translator/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/dfu-to-sql-translator/</link>
	<description></description>
	<lastBuildDate>Sun, 19 May 2013 03:14:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: TomLiotta</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/dfu-to-sql-translator/#comment-113851</link>
		<dc:creator>TomLiotta</dc:creator>
		<pubDate>Fri, 30 Nov 2012 06:38:55 +0000</pubDate>
		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/itanswers/dfu-to-sql-translator/#comment-113851</guid>
		<description><![CDATA[DFU and SQL are not fully compatible, so conversion wouldn&#039;t be guaranteed. I can&#039;t imagine a product that could make the jump, especially since DFU is proprietary.
&#160;
Regardless, the &#039;Answer&#039; suggestion to use journaling (rather than either the database monitor or the DFU logging) is almost certainly best. SQL statement logging doesn&#039;t tell you what actually happened. Only journaling will tell you that. It&#039;s also more reliable, and it&#039;s actually acceptable for compliance and similar requirements where database monitor output would not be. (It&#039;s vulnerable to manipulation.)
&#160;
The database monitor is really appropriate for performance optimization. It&#039;s not well structured for audit logging. It leaves out important audit items, such as which rows were affected, or in fact whether any rows were affected at all. And of course, it&#039;s not appropriate for any non-database (non-SQL) I/O at all.
&#160;
Since there is no conversion between DFU and SQL, it seems reasonable that you need something different. It would be helpful if you could describe the &lt;EM&gt;business objective&lt;/EM&gt; that you&#039;re trying to satisfy.
&#160;
Tom]]></description>
		<content:encoded><![CDATA[<p>DFU and SQL are not fully compatible, so conversion wouldn&#8217;t be guaranteed. I can&#8217;t imagine a product that could make the jump, especially since DFU is proprietary.<br />
&nbsp;<br />
Regardless, the &#8216;Answer&#8217; suggestion to use journaling (rather than either the database monitor or the DFU logging) is almost certainly best. SQL statement logging doesn&#8217;t tell you what actually happened. Only journaling will tell you that. It&#8217;s also more reliable, and it&#8217;s actually acceptable for compliance and similar requirements where database monitor output would not be. (It&#8217;s vulnerable to manipulation.)<br />
&nbsp;<br />
The database monitor is really appropriate for performance optimization. It&#8217;s not well structured for audit logging. It leaves out important audit items, such as which rows were affected, or in fact whether any rows were affected at all. And of course, it&#8217;s not appropriate for any non-database (non-SQL) I/O at all.<br />
&nbsp;<br />
Since there is no conversion between DFU and SQL, it seems reasonable that you need something different. It would be helpful if you could describe the <em>business objective</em> that you&#8217;re trying to satisfy.<br />
&nbsp;<br />
Tom</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/8 queries in 0.011 seconds using memcached
Object Caching 269/270 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-19 04:23:00 -->