Search Comparisons Searching - Comparisons FieldNamecomp=XX
Searches using comparisons of data.

You can compare data during a search in many different ways -- the field may match exactly, greater than, less than, in a range, etc. You tell WebDNA how to compare fields in a database by typing the field name followed by comp into a URL. As a shortcut, you can also put the two-letter comparison code in front of the fieldname's data specifier.

If your database has a field called "FirstName", and you want to look for records that are alphabetically arranged after "Grant" in the FirstName field, then you would enter a URL something like this:

http://Results.tpl?command=search&FirstNamedata=Grant&FirstNamecomp=gr&db=SomeDatabase.db

shortcut equivalent form for the search above:
http://Results.tpl?command=search&grFirstNamedata=Grant&db=SomeDatabase.db

The template "Results.tpl" displays after the search, and any [FoundItems] contexts will be filled with found records. "gr" stands for "greater than," meaning the FirstName field must be greater than "Grant," otherwise it will not be considered a match.

Note: Probably the most commonly-used (and simplest) way to search a database is the "Word Or" search. This most closely matches Yahoo and Lycos' style of searching, because it finds all records matching at least one word entered by the visitor, and sorts the "best match" records to the top of the list. If you have a product database with a Description field, the search form might look like this:
 
<form method="POST" action="Results.tpl">
<input type=hidden name="command" value="Search">
Description: <input name="woDescriptiondata"> <input type="submit">
</form>

Below is a list of all the different ways to compare information in a field. All comparisons are not case-sensitive (unless you force them to be), so "JOE" is the same as "Joe":
Comp Description
 ls
less than - lsFirstNamedata=Grant finds all records whose FirstName field is "less than" Grant. Comparisons can be alphabetic, numeric, or date, depending on the type you specify for the field.
 le
less than or equal to - leFirstNamedata=Grant finds all records whose FirstName field is "less than or equal to" Grant.
 eq
equal to (default option for numbers) - eqFirstNamedata=Grant finds all records whose FirstName field is "equal to" Grant (upper and lower case do not matter unless you want them to: see Case Sensitivity)
 ge
greater than or equal to - geFirstNamedata=Grant finds all records whose FirstName field is "greater than or equal to" Grant.
 gr
greater than - grFirstNamedata=Grant finds all records whose FirstName field is "greater than" Grant.
 rn
range: field contains two values separated by spaces (or any other delimiter specified by wbrk). The values may be dates, numbers, or text. You must specify what type of data the fields are by using fieldnametype=xxx (where xxx is num or date).

rnZipCodedata=92069 93090&ZipCodetype=num finds all records whose ZipCode field is numerically in the range of 92069 - 93090

Note: When specifying a range, the smaller value must precede the larger value, i.e. rnZipCodedata=92069 93090, not rnZipCodedata=93090 92069.
 mr
minimum range value: if no maximum then ge is used instead
 xr
maximum range value: if no minimum than le is used instead
 ne
not equal - neFirstNamedata=Grant finds all records whose FirstName field is "not equal" Grant.
 bw
begins with - bwFirstNamedata=Jo finds all records whose FirstName field "begins with" Jo, as in "Joe", "Joseph", "Josephine".
 cl
close to (numeric only). clZipCodedata=92069&clZipCodedata=10 finds all records whose ZipCode field is within 10 of 92069 (92059 - 92079)
 ws
Interpret the words as a single string to be matched (including spaces etc.) This lets you find entire phrases, like "Joe enjoys butter" only if those 3 words are next to each other in that order, including spaces (unlike wa and wo, below)
 wa
Separate the words and "and" them together (all must match). Searching for 3 words using wa will match only if all 3 are in the field, but not necessarily next to each other.
 wo
Separate the words and "or" them together (at least one must match - default option for text). Search for 3 words using wo will match if any one of them matches.
 wn
word not equal - none of the words match text in the specified field

User Contributed Notes
SearchComparisons  

Donovan - lists(at)euca.us 
04/22/2009 at 17:30:22
**required comparisons**
I don't see this part in the interactive docs so I'll post it here. In WebDNA searching, you have the ability to require a comparison, or not require it. One can fine-tune a query, perhaps more than other languages, using the required param and other WebDNA params.

[search db=some.db&eqFIELD1datarq=something&..]

the 'rq' specifies that the 'eqFIELD1datarq=something' comparison is required to return a positive match.

Alternatively, there is a parameter that can globally set all comparisons to required.. I hope I get this right off the top of my head, but I believe it is:

&allreqd=T

All comparisons then must match in order to return a positive match in the founditems loop.

**Note** also, if a value of a particular comparison has the potential to be blank.. see 'Blank/Empty Fields' (to the left when clicking "Searching" at the top). You must specify that it is "O.K." to match for blank values in order for the "required" to "stick" on that comparison.

Donovan

Govinda - govinda dot webdnatalk at gmail dot com 
08/26/2009 at 18:02:10
It seems (from testing just now) that webdna does not use multiple comparison parameters when they are both "ne" (prefix) and "rq" (suffix).  I had to switch to "wn" (prefix) to get my search to stop finding records where the field was equal to "foo" *OR* "bar".

In other words, this:

[Search db=^db/blah.db&neTheUserdatarq=mydemo&neTheUserdatarq=me]

found all records in the db.

(!??)

but this:

[Search db=^db/blah.db&wnTheUserdatarq=mydemo&wnTheUserdatarq=me]

did the right thing (finds all but those 2 records).

Govinda - govinda dot webdnatalk at gmail dot com 
05/13/2010 at 15:38:54
disregard my note just above.  When I wrote that I had forgotten that the use of 'Groups' are required when searching the same field more than once.  See the section "Grouping Fields".  Sorry for the noise.  Whoever has access to these, please delete my above entry. Thanks, -Govinda  

Copyright © 2008 WebDNA Software Corporation, Inc.