One of the ignorances has to do with unfamiliarity with set programming plus premature optimization. <br><br>Many production SQL code I've seen use concatenations to generate dynamic sql statements for creating different where clauses and return different columns, which of course leads to
SQL injection problems (as well as difficult to debug SQL query/stored procedures). Often the developers in charge (even experienced ones) don't know how to write one single sql statement to represent the "different" sql statements (even if they know how to do so they rather use dynamic SQL to write more compact thus "optimized" statements). The same developer often is more comfortable write cursors and loops rather than using selects appropriately.
<br><br><br><div><span class="gmail_quote">On 5/31/07, <b class="gmail_sendername">Danny Yoo</b> <<a href="mailto:dyoo@cs.wpi.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dyoo@cs.wpi.edu</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think it's ignorance.<br><br>When I was doing Python programming, I saw newcomers work with the Python<br>DBI and almost always not use prepared statements but rather string<br>concatenate. That's what their teacher told them to do. And even people
<br>who should know better can propagate this problem. Here's one example:<br><br> <a href="http://mail.python.org/pipermail/tutor/2003-April/022010.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://mail.python.org/pipermail/tutor/2003-April/022010.html
</a><br><br>I saw the same thing with many Java programmers: I rarely saw use of<br>prepareStatement(), and even when I saw people using it, the code would<br>completely miss the point of prepareStatement(); I'd see code like:
<br><br> stmt = conn.prepareStatement("insert into article (title) values ('" +<br> title + "')");<br> stmt.executeQuery();<br><br>which made me laugh and cry at the same time.
<br><br><br><br>I'm very glad that Hans's SQLID interface includes support for prepared<br>statements. I would like to see it highlighted more vividly in the<br>documentation. As it is, it's just a quick mention in:
<br><br><a href="http://www.elemental-programming.org/sqli.html#_code__sqli_query_sqli_handle_query___args____boolean__code_" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.elemental-programming.org/sqli.html#_code__sqli_query_sqli_handle_query___args____boolean__code_
</a><br><br>as a set of optional arguments passed to the "query" method.<br>_________________________________________________<br> For list-related administrative tasks:<br> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br></blockquote></div><br>