-
Website
http://awads.net/wp/ -
Original page
http://awads.net/wp/2007/10/09/beware-of-comments-in-sql/ -
Subscribe
All Comments -
Community
-
Top Commenters
-
jgarry
3 comments · 1 points
-
Andy C
22 comments · 47 points
-
dahowlett
1 comment · 2 points
-
Don Seiler
9 comments · 1 points
-
davidhaimes
4 comments · 3 points
-
-
Popular Threads
That seems so stupid from Oracle, Eddie.
Does this apply to all versions?
I do not know if this applies to all versions. We have Oracle Forms version 6, EBS 11.5.10 and a 10gR1 database.
The /.../ style comments are much better if you ever have to dig SQL out of the V$SQL views
[That looks odd - looks like it did something to the asterisks - try again /../]
Gary, right, it's better. The only disadvantage of the slash and asterisk commenting style is that it requires more typing than the double hyphen.
By the way, the stupid Markdown syntax ate the asterisks *. Sorry. I used the backslash \ to escape it.
Huh, I've never experienced that so thanks for the tip. However, the biggest sin he committed was hard-coding a value instead of referencing the block.field value. Think of the noobs who will see this and do the same. ;)
Matt, thanks for your tip too. I agree with you, hardcoding should be avoided. However, the query above is not the actual query that is used in the form. I just used a simple query here for demonstration purposes and to illustrate the problem that we faced.
So you mean, "Beware of comments in Oracle Forms LOV definitions"? That's not the same thing as "Beware of Comments in SQL".
William, sure, if you want to be picky :) I can be even pickier: "Beware of double hyphen style comments in Oracle Forms LOV definitions".
But, I can think of at least a couple of situations that have nothing to do with LOVs in Oracle Forms and where double hyphen style comments inside SQL can cause problems.
While debugging ColdFusion web applications, the SQL used in these applications is logged, usually as a long string with no line breaks. Having a double hyphen comment in the middle of it will cause a problem when trying to execute it as is. I usually need to edit the SQL first, which is a hassle. I think this is indirectly related to Gary's comment above.
The second situation is, well, rather simple. For example:
<pre>
SQL> select * from dual;
</pre>D
-
X
SQL> select * -- comment here from dual;
select * -- comment here from dual
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected
SQL> select * /* comment here */ from dual;
D
-
X
Powel also shared an interesting thing about comments in SQL*Plus.
Well, duh ;)
Though it did remind me of the colleague who couldn't work out why he got a "missing expression" error with something like this:
EXECUTE IMMEDIATE
'SELECT --+ FULL(e) ' ||
' COUNT(*) ' ||
'FROM emp e ' ||
'WHERE e.empno = 42' INTO v;
...only with the line breaks I posted left in...
http://coskan.wordpress.com/2007/04/23/oracle-i...