Embedded SQL parameters are there for protection - concatenating the statement and quoting literal arguments from variables is not safe and wastes time. Eg. do this:

  <SQL "select x from tbl where y like $query">

NOT this:

  <SQL "select x from tbl where y like '" $query "'">

It's easy to fall into this trap if you've had experience in other scripting languages.

Errors like Query would require linear search are there to protect your server from bogging down on poorly formed SQL and/or bad user queries. If you get them, don't just turn 'em off in <apicp> to let the query through. Fix your application and indexes, you're probably missing some indexes or doing the query in a less efficient manner.

Texis and Metamorph are designed for multi-word queries; it's what we do. Don't do this:

  <SQL "select x from tbl where x like 'aaa' and x like 'bbb'
             and x like 'ccc'">

because it takes 3 searches instead of one. Instead do this:

  <SQL "select x from tbl where x like 'aaa bbb ccc'">

because like requires all these terms to be present, and can do the search in one pass.

Multi-value text parameters in <SQL> become parenthetical comma-separated strings. This is intended for set lists in a Metamorph query. But in a non-select clause (eg. insert ), it'll just give you the wrong value:

  <SQL MAX=3 "select x from table1"></SQL>
  ...
  <SQL NOVARS "insert into table2 values($x, 5, 'now')"></SQL>
  <!-- whoops, $x is multi-value from that previous select:
    -- our insert gets a paren list accidentally.
    -->

The right way:

  <SQL MAX=3 "select x from table1"></SQL>
  ...
  <LOOP $x>
    <SQL NOVARS "insert into table2 values($x, 5, 'now')"></SQL>
  </LOOP>

It's easy to miss that a var is really multiple values, because when you print it, only the first value would be printed anyway. If you're unsure, <LOOP> over it to see if it has more values.

Not just select statements, but update and insert return rows and variables as well, and they return the entire row - all columns. It's easy to blow away a variable without knowing it:

  <!-- schema: create table bob(x int, txt varchar(10)) -->
  <$txt = "Some important string to save">
  <SQL "update bob set x = 5 where x = 4"></SQL>
  <!-- We just blew away our $txt value, even though it's not mentioned
    -- directly in the update: update returns the whole row.
    -- Use NOVARS:
    -->

  <SQL NOVARS "update bob set x = 5 where x = 4"></SQL>

Variables accumulate rows in <SQL> , <TIMPORT> , <rex> and <xtree> loops. If you only need them one at a time, and you're selecting a lot of them, use ROW to save memory.

REX is your friend. Get to know it. Regular expressions have far more power and speed than stringing along with copious calls to C-style functions like <strstr> .

If you're only exporting a small variable like a user name or id, use URL export - it's faster.

After a variable is exported, especially to the URL, it should be cleared if not needed, to prevent it cluttering up the next URL. For example:

  <SCRIPT LANGUAGE=vortex>

  <EXPORT $id URL>

  <A NAME=main>
    ...
    <SQL MAX=25 "select id, Title from books ...">
      <!-- $id has only one value here for $url: -->
      <A HREF=$url/details.html>$Title</A> <P>
    </SQL>
    <!-- $id now could have 25 values, and we don't need 'em;
      -- this $url will be unnecessarily long:
      -->
    Link to <A HREF=$url/other.html>unrelated function</A>
  </A>

At the second $url , we don't care about $id being exported to other . But it's still set, and to 25 values: that URL will be very long.

To avoid this, we clear $id just before the second $url reference. (Or move its values to another non-EXPORT var for safekeeping, if we still need them this invocation.)

Leading literal whitespace is truncated in the output. Also, trailing newlines after functions are stripped too, so that multiple non-output-generating function calls don't print a bunch of newlines. This lead to unexpected results when functions are strung together on a line. Use <fmt> or <send> to insert whitespace as needed.

A period is a valid character for a variable in Vortex; this allows image map vars to come through. But sometimes you want a real period after the var:

  The cost is $price.  That's all.

Instead of printing $price , we're actually referring to $price. which probably is unset. Quote the var:

  The cost is $'price'.  That's all.

Some names in Vortex are case-sensitive (variables and in-script functions), while others are case-in sensitive (<SQL> , <LOOP> tags). You can always spell a reserved Vortex name in lower-case, regardless of sensitivity. Also, any reserved name that is in upper-case in the manual is case-insensitive.