<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Master for Webs &#187; Oracle</title>
	<atom:link href="http://master4webs.com/tag/oracle/feed" rel="self" type="application/rss+xml" />
	<link>http://master4webs.com</link>
	<description>All tools for web masters</description>
	<lastBuildDate>Sun, 02 Oct 2011 08:08:36 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>QUERY and the Database</title>
		<link>http://master4webs.com/query-and-the-database.html</link>
		<comments>http://master4webs.com/query-and-the-database.html#comments</comments>
		<pubDate>Fri, 26 Jun 2009 12:46:05 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Database]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Oracle]]></category>
		<category><![CDATA[QUERY]]></category>
		<category><![CDATA[QUERY synopsis]]></category>

		<guid isPermaLink="false">http://master4webs.com/?p=100</guid>
		<description><![CDATA[Not needing a SQL database for every site or every table means you can use Interchange in more hosting environments, but that&#8221;s has usually come at the cost of being able to use SQL as your query language. Fortunately Interchange comes with a built-in SQL interpreter, which means you can use a single query language [...]]]></description>
			<content:encoded><![CDATA[<p>Not needing a SQL database for every site or every table means you can use Interchange in more hosting environments, but that&#8221;s has usually come at the cost of being able to use SQL as your query language. Fortunately Interchange comes with a built-in SQL interpreter, which means you can use a single query language even if your tables are stored in a &#8220;flat file&#8221; instead of something like MySQL or Oracle. <span id="more-100"></span></p>
<p>The QUERY tag is the main interface for executing arbitrary SQL on any table, regardless of the back-end.</p>
<h2>QUERY synopsis</h2>
<pre>[query
	list="1"
	sql="SELECT * FROM products WHERE prod_group = 'Toys'"]

	&lt;li&gt;[sql-param description] - [price [sql-code]]&lt;/li&gt;

[/query]</pre>
<h3>Step 1</h3>
<p>QUERY is a container tag surrounding code that&#8217;s repeated for each row returned by the query, so it always has a closing tag.</p>
<h3>Step 2</h3>
<p>Passing <code>list="1"</code> tells Interchange that you&#8217;re expecting a &#8220;list&#8221;&#8211;or multiple rows, in other words. If you don&#8221;t pass this, the code surrounded by the QUERY tags won&#8221;t be executed. You need to pass this even if you&#8221;re only expecting one row in the results.</p>
<p>If you remember that &#8220;SELECT is a LIST&#8221; it won&#8221;t be a problem. But the QUERY tag is versatile enough that you can also run UPDATE and INSERT queries, and for these you can omit the <code>list="1"</code> parameter. You&#8217;ll still need a closing QUERY tag, though.</p>
<h3>Step 3</h3>
<p>The actual query is passed in the <code>sql="SELECT..."</code> parameter. From within here you can also use other Interchange tags, such as SCRATCH. Remember to quote anything, where necessary, like this:</p>
<pre>[query
	list="1"
	sql="SELECT * FROM products WHERE prod_group = '[scratch prod_group]'"]

	... your code here ...

[/query]</pre>
<p><strong>Security warning:</strong> It&#8217;s tempting to pass user input in some form when creating queries. Writing <code>prod_group='[CGI prod_group]'</code> is a quick and easy way to start a search results page, but it can be exploited by a hacker, who could pass something like this:</p>
<pre>	foo'; delete from products where sku != '</pre>
<p>In this example, the ending quote and semicolon after <code>foo</code> closes the WHERE clause of the first query and then closes the query. The following query can then be executed, deleting all the products in your store. The code reading <code>where sku != '</code> just makes sure there&#8217;s no syntax error that&#8217;d otherwise stop his malicious query from running.</p>
<p>To avoid accidents like this, you can screen incoming user data for quote marks and save the result in a scratch variable, like this:</p>
<pre>[tmp prod_group][calc]
	my $group = $CGI-&gt;{prod_group};
	$group =~ s/'/''/g;
	return $group;
[/calc][/tmp]</pre>
<p>The perl code here is substituting each single quote for a <em>pair</em> of single quotes (that&#8217;s not a double quote there, it&#8217;s two singles), which is how most SQL databases encode the quote character for use within strings passed to queries. With that in place, the hacker can&#8217;t get a malicious query to run, because he can&#8217;t break out of the first. In the worst case, the query would simply fail rather than delete all of your products.</p>
<p><strong>You should always screen form-submitted data</strong> even if you&#8217;re passing it through hidden variables, or SELECT lists that constrain the input. None of these methods stop a hacker from contriving a GET or POST form submission with whatever he likes.</p>
<h3>Step 4</h3>
<p>The code to be run for each row of results is interpolated for SQL tags. The first useful tag is SQL-PARAM, which lets you pull any column from the results, even computed, virtual or renamed columns. For example:</p>
<pre>[query
	list="1"
	sql="SELECT sku,description,
		date_format(entered,'%Y-%m-%d') as added,
		price + 10 as compare
		FROM products"]

	&lt;li&gt;[sql-param description] added [sql-param added]
		- [price [sql-code]] (compare to $[sql-param compare])&lt;/li&gt;

[/query]</pre>
<h2>Advanced</h2>
<h3>ON-MATCH and NO-MATCH</h3>
<p>Like with Interchange&#8217;s tags for summarizing search results, QUERY also understands the ON-MATCH and NO-MATCH tags to display something once when it finds rows, or doesn&#8217;t.</p>
<pre>[query
	list="1"
	sql="SELECT * FROM products WHERE prod_group = '[scratch prod_group]'"]

	[on-match]
		&lt;p&gt;We found the following products for [scratch prod_group].&lt;/p&gt;
		&lt;ul&gt;
	[/on-match]

	[list]
		&lt;li&gt;[sql-param description] - [price [sql-code]]&lt;/li&gt;
	[/list]

	[on-match]
		&lt;/ul&gt;
	[/on-match]

	[no-match]
		&lt;p&gt;Sorry, no matches for [scratch prod_group].&lt;/p&gt;
	[/no-match]

[/query]</pre>
<p>When you use the ON-MATCH or NO-MATCH tags, you imply the use of LIST as well. That&#8217;s because Interchange wouldn&#8217;t otherwise know what part of the code is meant to be repeated for each row.</p>
<p>In this example, there are two ON-MATCH blocks wrapped around the list to open and close a pair of HTML Unordered List tags. But you could also use them to open and close tables, paragraphs, or whatever.</p>
]]></content:encoded>
			<wfw:commentRss>http://master4webs.com/query-and-the-database.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

