Just to add to the earlier comments, you should normally use dbisql with IQ. However, using the Ct-library-based 'isql' utility can sometimes be more useful. For example:
- when you need a command-line ASCII interface (i.e. when you're in a remote shell session) and you need to run multi-line SQL commands. dbisql doesn't do this well, but isql does.
- in case you need to debug long SQL script files that you're executing from the command line. When an error occurs in such a script, it is easier to locate the error with isql (using the -e option), than with dbisql.
- command batches that return multiple result sets are easier handled with isql than with dbisql
To avoid unexpected behaviour when using isql instead of dbisql, you should ensure the session-level settings are set to the Watcom defaults. I keep this stored proc around to execute after I have connectd to IQ or SQL Anywhere with isql:
CREATE OR REPLACE procedure dbo.set_watcom_defaults()
begin
if connection_property('CommProtocol') = 'TDS'
then
/* This is a TDS connection, set session options to the Watcom defaults.
* This overrides the TDS defaults set at connection time by sp_tsql_environment()
*/
set temporary option ansinull = 'ON';
set temporary option tsql_variables = 'OFF';
set temporary option ansi_blanks = 'OFF';
set temporary option chained = 'ON';
set temporary option quoted_identifier = 'ON';
set temporary option allow_nulls_by_default = 'ON';
set temporary option on_tsql_error = 'CONDITIONAL';
set temporary option isolation_level = '0';
set temporary option date_format = 'YYYY-MM-DD';
set temporary option timestamp_format = 'YYYY-MM-DD HH:NN:SS.SSS';
set temporary option time_format = 'HH:NN:SS.SSS';
set temporary option date_order = 'YMD';
set temporary option escape_character = 'ON';
set temporary option ansi_substring = 'ON'; -- NB: default=ON for SA, OFF for IQ.
end if;
end