Hi. Well SQL Validation does allow you to pull in tokens (fields) but there needs to be only one column returned within the SQL and this column needs to be called 'IsValid'. If it returns false or 0 then it will return the error message and not pass, if it returns anything else it will return true. So... Not sure specifically your instance but are you pulling information from the database table? Here is an example:
Lets let the user enter a username, we will check the database and if that user exists it will return the UserID, if it doesn't it will return 0.
Select count(*) from Users where UserName = '$(UserName)'
This assumes that a short field name of UserName exists on the form. The SQL will check the database and will return either a 1 (user exists) or 0 (user does not exist).
For all SQL VAlidation you should always use stored procedures though. You will want to pass the field tokens to a stored procedure and have it handle the validation. Basically this allows you to use safe (avoid SQL Injection) methods for SQL Validation but it also allows you to put more logic within SQL validation. You could technically have all types of logic within the stored procedure, maybe if / else statements, select case statements, or other logic and then simply return 'True' or 'False' to one column called IsValid. We will try and post more real life scenarios with demonstrations down the road. SQL Validation is new for 2.6 and we will actually be changing it down the road to be on each field level (so you can run multiple validation instead of a single validation for the entire form).
-Chad