<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Eddie Awad’s Blog - Latest Comments in Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.disqus.com/</link><description>News, views, tips and tricks on Oracle and other fun stuff</description><atom:link href="https://awads.disqus.com/oracle_in_3_minutes_a_ticking_bomb/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Tue, 11 Dec 2007 00:29:50 -0000</lastBuildDate><item><title>Re: Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.net/wp/2007/12/10/oracle-in-3-minutes-a-ticking-bomb/#comment-3659426</link><description>&lt;p&gt;@Justin: Good points.&lt;/p&gt;&lt;p&gt;One more thing, if the to_char is used in the WHERE clause, that will break the use of indexes which may impact performance. So, a function based index may be a good option here.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Eddie Awad</dc:creator><pubDate>Tue, 11 Dec 2007 00:29:50 -0000</pubDate></item><item><title>Re: Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.net/wp/2007/12/10/oracle-in-3-minutes-a-ticking-bomb/#comment-3659427</link><description>&lt;p&gt;When trying to filter out rows, be aware that there is no guarantee about what order Oracle executes the various conditions.  So you might well find that the invalid number error returns down the road when the query plan changes.&lt;/p&gt;&lt;p&gt;Even if you nest the subquery, i.e.&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;pre&gt;SELECT t1.col1, t2.col2&lt;br&gt;  FROM (SELECT t.col1 &lt;br&gt;          FROM table1 t &lt;br&gt;         WHERE filter_out_non_numbers) t1,&lt;br&gt;       table2 t2&lt;br&gt; WHERE t1.col1 = t2.col1&lt;br&gt;&lt;/pre&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;there is no guarantee that the inner subquery is logically materialized before the join (and the implicit conversion) happens.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Justin Cave</dc:creator><pubDate>Mon, 10 Dec 2007 21:59:05 -0000</pubDate></item><item><title>Re: Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.net/wp/2007/12/10/oracle-in-3-minutes-a-ticking-bomb/#comment-3659428</link><description>&lt;p&gt;Yeah, reality sometimes is so far way from the "ideal" world :-)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Patrick Wolf</dc:creator><pubDate>Mon, 10 Dec 2007 15:25:28 -0000</pubDate></item><item><title>Re: Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.net/wp/2007/12/10/oracle-in-3-minutes-a-ticking-bomb/#comment-3659429</link><description>&lt;p&gt;@Patrick: Sure, if you can change the data model, that will be a very good solution. But, sometimes reality hurts and you're stuck with a model that you have no control over. I sometimes do find myself in such a situation, unfortunately, especially when I deal with FlexFields (varchar2 columns) in Oracle EBS.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Eddie Awad</dc:creator><pubDate>Mon, 10 Dec 2007 15:21:09 -0000</pubDate></item><item><title>Re: Oracle in 3 Minutes: A Ticking Bomb</title><link>http://awads.net/wp/2007/12/10/oracle-in-3-minutes-a-ticking-bomb/#comment-3659430</link><description>&lt;p&gt;Solution 3:&lt;/p&gt;&lt;p&gt;Reconsider your data model if you are really going to compare two columns which obviously have the same content and meaning but are of different data type...&lt;/p&gt;&lt;p&gt;:-)&lt;br&gt;Patrick&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Patrick Wolf</dc:creator><pubDate>Mon, 10 Dec 2007 15:11:42 -0000</pubDate></item></channel></rss>