Interactive SQL behavior changes and deprecated features

Following is a list of changes to Interactive SQL introduced in version 12.0.0.

  • Support for 32- and 64-bit computers  

    • Now, you can have both 32- and 64-bit versions of Interactive SQL installed on the same computer.

  • Changes to the default encoding for Windows   The following change applies to running Interactive SQL as a console application (with no windowed user interface) on Windows computers where the ANSI and OEM encodings differ, for example on a U.S. English Windows XP computer.

    1. Previously, when running Interactive SQL as a console application, the INPUT and READ statements assumed that the file was encoded using the OEM encoding (cp437 on a U.S. English Windows XP computer) in the absence of an explicit ENCODING clause. Similarly, the OUTPUT statement would output the file using the OEM encoding.

      Now, when running Interactive SQL as a console application, the INPUT and READ statements assume that the file is encoded using the ANSI encoding (cp1252 on U.S. English Windows XP computer). Similarly, the OUTPUT statement outputs the file using the ANSI encoding.

      At a command prompt, to process a file that uses the OEM encoding, you must specify the encoding explicitly. For example:

      dbisql READ ENCODING 'cp437' myfile.sql
    2. Previously, when running Interactive SQL as a console application, results written to and read at a command prompt used the ANSI encoding (cp1252 on a U.S. Windows XP computer), which could cause extended characters to be displayed incorrectly.

      Now, when running Interactive SQL as a console application, results written to and read at a command prompt use the OEM encoding (cp437 on a U.S. Windows XP computer).

    See default_isql_encoding option [Interactive SQL].

  • Change to the CLEAR statement, Clear menu item, and the Esc key   Now, the CLEAR statement closes any open result sets and leaves the contents of the SQL Statements pane unchanged. See CLEAR statement [Interactive SQL].

    Also, the Edit » Close Results menu item, which is equivalent to executing a CLEAR statement, closes any open result sets and leaves the contents of the SQL Statements pane unchanged.

    The Edit » Clear menu item which used to clear the contents of the SQL Statements pane has been removed. As a result, the keyboard shortcut for the Clear menu item, the Esc key, has also been removed. Now by default, pressing the Esc key has no affect.

    However, you can set the Esc key to clear the SQL Statements pane and close any opened result sets. Click Tools » Options » Compatibility and click Pressing The Esc Key Clears SQL Statements And Closes Result Sets.

  • -codepage option removed   If you want Interactive SQL to read a file with a specific code page, use the ENCODING clause of the INPUT, OUTPUT, or READ statements. The -codepage option has been removed from the software. See:

  • Change to SET OPTION statement [Interactive SQL]   Previously, if you used the SET OPTION statement to set an option and didn't specify a value, the option was set to Off. Now, if the option value is omitted, the specified option is set to its default value. This change affects the following options: auto_commit, auto_refetch, bell, commit_on_exit, and echo. See SET OPTION statement [Interactive SQL].

  • Change to OUTPUT statement   When outputting results to a TEXT file, you can use the WITH COLUMN NAMES clause to insert the column names at the beginning of the file. See OUTPUT statement [Interactive SQL].

  • Change to INPUT statement   When inserting lines from a TEXT file with the INPUT statement, you can now use the SKIP clause to specify a number of lines to omit from the start of the file. See INPUT statement [Interactive SQL].

  • READ keyword no longer required   When you run Interactive SQL at a command prompt, the READ keyword is optional when specifying a .sql file to run. If the .sql file requires parameters, specify the parameters after the file name.

    For example, the following two commands are equivalent:

    With the READ keyword Without the READ keyword
    READ file.sql parm1
    file.sql parm1

    See Interactive SQL utility (dbisql).

  • Improvements to Microsoft Excel ODBC driver support   The following list describes changes related to exporting data from SQL Anywhere to Excel files via the Microsoft Excel ODBC driver:

    • Previously you could not export data that was stored as a CHAR, LONG VARCHAR, NCHAR, NVARCHAR, or LONG NVARCHAR data types.

      Now when you export data that is stored as a CHAR, LONG VARCHAR, NCHAR, NVARCHAR, or LONG NVARCHAR data types from a SQL Anywhere database using the Microsoft Excel ODBC driver, the data is stored as VARCHAR (the closest type supported by the Excel driver).

      The Microsoft Excel ODBC driver supports text column widths up to 255 characters.

    • You can export data that is stored as REAL, FLOAT, and BIGINT data types.

    • Data stored as MONEY and SMALLMONEY data types are exported to the CURRENCY data type. Otherwise numerical data is exported as numbers.

    • You can use the Export Wizard to export tables.

    See Data export.