Jeff, just one thing to consider when building SQL strings: "SQL Injection" is where a hacker supplies a parameter that alters the result.

Example:

Say you want to allow sales agents to look-up their own customers but not all your other customers. The agent enters the customer ID and the details are displayed. Here is the SQL used for the lookup:

lcagent=<agent's unique id>
lcID=<customer's unique id entered by agent>
lcselect=[select * from customer where cAgent="]+lcAgent+[" and ccustomerID="]+lcID+["]
&lcselect

Obviously this SQL prevents agent1 from accessing customers "owned" by agent2.

But say a hacker enters the customer ID as JJ" or ccustomerID != "?

You end up with this SQL:

select * from customer where cAgent="agent1" and ccustomerID="JJ" or ccustomerID != "?"

This SQL will reveal the entire customer list.

It's a trivial example, but something that could appear anywhere SQL is built from user input.

IMHO the best response is to use parameterised queries:

lcagent=<agent's unique id>
ccustomerID=<customer's unique id entered by agent>
lcselect=[select * from customer where cAgent=?lcAgent and ccustomerID=?lcID]
&lcselect

The ? parameters automatically insert the variable content at that point. It cannot have SQL injected. It is also easier to maintain IMHO and works against SQL server and other backends as well.