This document describes a number of possible errors and warnings that customers upgrading from versions 2.5.x or 3.0.

x to version 4.x.x or 6.x.x may encounter.

1. Using an edit mask when moving an SQR string variable to a numeric variable worked in version 3, but in version 4, a 7100 error is generated. This change is by design. Here is some sample code:
move $var to #var edit 09999999 print #var (1,1) The complete error is: (SQR 7100) The use of an edit mask or the keywords NUMBER, MONEY or DATE is not legal when storing numeric variables. One workaround is to not use the edit mask and print the #var with the NUMBER edit mask after altering the number-edit-mask value. For example: move $var to #var alter-locale number-edit-mask='09999999' print #var (1,1) number Another workaround is to move the string variable to itself with a string edit mask. For example: move $var to $var edit '09999999' print $var (1,1)

2. The date-time command can no longer be used inside of a select statement. Here is some sample code that no longer works:
begin-select col1 date-time (1,1) from table1 end-select The complete error is: (SQR 3702) Command not allowed in this section: date-time One workaround is to use the datenow function that was introduced in version 4. For example: begin-select col1 let $date = datenow() print $date (1,1) from table1 end-select Another workaround is to put the date-time command into a procedure and call the procedure from the select statement. For example:

begin-select col1 do date_time from table1 end-select end-procedure begin-procedure date_time date-time (1,1) end-procedure

3. Input of dates with SQR for Oracle has changed. With V3, the default format for Oracle was a 2-digit year. With V4, the default is a 4-digit year. This means that input statements that worked in V3 need an additional option to work the same in V4. For example:
input $date type=date Must be changed to: input $date type=date format='dd-mon-yy'

4. Sybase changed the format of how char columns with blanks at the end are returned with CT-Lib versus DB-Lib. This means that SQR for CT-Lib (V3 and above) acts differently than SQR for DB-Lib (V3 and before). With DB-Lib a char column did not include the blanks at the end, but with CT-Lib, the blanks are included. To emulate DB-Lib functionality with SQR for CT-Lib, the -TB flag should be used on the command line. 5. SQR for Sybase CT-Lib no longer supports distinct database connections for the begin-select, begin-sql, and execute commands. SQR instead uses the Sybase cursors feature that was introduced with CT-Lib. Any Cnn flag for specifying the logical connection number is no longer needed. SQR will ignore the flag if still used. One consequence is that temporary tables with the same name can no longer be created in separate connections. For example, the following code which was acceptable in V2.5:
begin-setup begin-sql C1 create table ##temp (col1 varchar(10)) end-sql begin-sql C2 create table ##temp (col1 varchar(10)) end-sql end-setup Will give the following error in SQR for CT-Lib versions: (2714) There is already an object named '#temp' in the database.

6. SQR 2.5 did not complain about nested begin-procedure sections such as this:
begin-procedure main print 'test' (+1,1) begin-procedure main2 print 'test2' (+1,1) end-procedure end-procedure SQR 4.0.x and above will correctly give the following error: (SQR 3702) Command not allowed in this section: begin-procedure

7. Potentially ambiguous code that did not give a warning message in V2.5, will give a warning with V3.0 and higher. For example, the following command:
let #n2 = #n1-1 Gives the warning: (SQR 4039) '#n1-1' assumed to be a variable name, not an expression. To not get the warning, the command should be written as follows and the dash character should be used carefully in variable names: let #n2 = #n1 - 1

8. With SQR version 2.5, when using the -D flag to display SQR output as it is printed, there were formfeed characters placed in the output. To achieve the same output in V4, version 4.3.1 or higher is required and the following line must be added to the [Default-Settings] section of the SQR.INI file:
OutputFormFeedWithDashD = TRUE | FALSE

9. Using a date edit mask on a string variable that is a partial date string does not work the same in V4 as it did in prior releases. For example, the following code would work before V4:
begin-report let $d = 'Aug' let $v = edit($d,'mm') show $v end-report But in V4, the following error would occur: (SQR 1944) The date 'Aug' is not in the format specified by SQR_DB_DATE_FORMAT or in one of the accepted formats listed below Mon DD YYYY [HH:MI[:SS[.NNN]][AM | PM]] Mon DD YYYY [HH:MI[:SS[:NNN]][AM | PM]] YYYYMMDD [HH:MI[:SS[.NNN]][AM | PM]] YYYYMMDD [HH:MI[:SS[:NNN]][AM | PM]] SYYYYMMDD[HH24[MI[SS[NNNNNN]]]]

This error is caused by changes that were made when the date datatype was introduced in version 4. The changes make it mandatory for strings that have date edit masks applied to them to be in one of the default date Since this is how SQR now functions, you will need to workaround this problem by using the strtodate function as follows: let $v = edit(strtodate($d,'mon'),'mm')

10. SQR 4.3.1 or higher now generates warning messages when an edit mask contains a 2-digit year (YY or RR).
(SQR 7501) Using YY edit mask from (MM/DD/YY) against (1998) This message is controlled by a parameter in the [Default-Settings] section of the SQR.INI file: OutputTwoDigitYearWarningMsg = TRUE | FALSE

11. SQR 4.0 or higher will ignore database commands that alter date format. For example, the following Oracle command:
begin-sql ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY' end-sql Will not have any affect in an SQR program. The proper way to change date format is by using the SQR_DB_DATE_FORMAT setting in the SQR.INI file. For example: [Environment:Oracle] SQR_DB_DATE_FORMAT=DD-MON-YYYY

12. There are possible performance implications when upgrading from a Sybase/DB-Lib version of SQR to a Sybase/CT-Lib version.
All SQR versions prior to version 3.0.x were done using the DB-Lib interface. Versions 3.0.5 through 3.0.13.3 offered both CT-Lib and DB-Lib interface. Versions greater than 3.0.13.3 were done using the CT-Lib interface. SQR for CT-Lib uses cursors to perform select statements. Sybase has documented that cursors are slower than set operations in their Performance and Tuning Guide. The factors that degrade performance are locking, network activity, and processing overhead. The documented example shows a 250% increase in time when using cursors. Results can vary widely based on factors such as busy networks, number of active database users, and multiple users accessing the same table. The Sybase Performance and Tuning Guide can be accessed at the following URL: http://sybooks.sybase.com/onlinebooks/group-as/asg1150e/perform Chapter 12: Cursors and Performance discusses cursor performance in the section titled Comparing Performance With and Without Cursors.

13. Printing a numeric &column that has a null value with an edit mask printed blanks in V3, but V4 will print 0. The same functionality change applies to the move command and the edit function of the let command.
Example commands are as follows: begin-select &col (1,1) edit 999 move &col to $col1 999 let $col2 = edit(&col,999) from table1 end-select The workaround is to use the edit mask 999NU.

14. Using a bind variable in an expression or function will no longer work with SQR V4 running against the Ingres database.
Example commands are as follows: move 1 to #num1 ! Example of an expression begin-select quantity - #num1 &num2 from ordlines end-select move 01/01/1999 to $begin_date begin-select date($begin_date) &begin_date end-select The error is: (SQR 1305) CMPSQL: Unknown data type in database: 0. This was determined to be a vendor issue. Ingres does not return any datatype when an Ingres functions' arguments are passed via a parameter (e.g. float8($X)). In SQR V3 all column data was returned as characters strings. Numeric columns were detected by checking that the column datatype was actually numeric in nature. All others were considered strings. SQR V4 now requires that the datatype be accurate. Since SQR cannot determine the type it throws an error message. SQR cannot assume, as it did in SQR V3, that anything other than a numeric column is a string. The workaround is to use a dynamic column as follows: move 1 to #num1 ! Example of an expression let $num = quantity || to_char(#num) begin-select [$num] &num=number from ordlines end-select let $col = 'date(' || '''' || $begin_date || '''' || ')' ! Example of a function begin-select [$col] &begin_date=char end-select ! Example of a function

15. Attempting to insert a variable of zero length into a field defined as NOT NULL no longer works with SQR V4 running against the Ingres database.
Example commands are as follows: let $condition= '' let #i = 100 begin-sql insert into table1 values ($condition, #i) end-sql The error is: INGRES SQL OPEN/EXECUTE error -32000 in cursor 3: E_AD1012 An attempt to place a null value in a non-nullable datatype This was an intended change to how SQR works with Ingres so that it is consistent with regard to all other supported databases. The workaround is to use dynamic SQL as follows: let $insert = 'insert into t33589 values ' || '(' || '''' || $condition || '''' || ',' || $i || ')' begin-sql [$insert] end-sql

16. Selecting a column whose data is a blank character does not work the same with SQR V4 as it did with V3 when running against the Ingres database.
The following code creates a table with two columns. The second column is a varchar column that has a default value of 1 blank character. When this program was run using SQR V3, the second select statement would return a row. When run with SQR V4, it does not return a row. begin-setup begin-sql on=error=skip drop table test ; create table test (col1 integer not null default 0, col2 varchar(4) not null default ' ') ; insert into test (col1) values (1) end-sql end-setup begin-program begin-select col2 let $col2 = &col2 from test where col1 = 1 end-select begin-select col1 col2 from test where col2 = $col2 end-select end-program

The issue is that a blank is being inserted into a character field. SQR for Ingres automatically removes trailing blanks from character columns. Therefore the comparison in the second selects where clause will fail. There is no mechanism to inhibit the trailing character removal. This program should never have returned any rows for the second select statement.