Bug 39531

Critical

GemConnect

2.4, 2.3, 2.2.3, 2.2.2, 2.2.1, 2.2, 2.1.1, 2.1

All platforms

CR's (carriage returns) stripped from SQL statements

In GemConnect 2.1, we "fixed" a problem with Oracle parsing of stored procedures
by scanning SQL strings passed via GemConnect #openCusorOn:* or #execute:*
methods, and replacing any carriage returns with spaces before passing
them on to Oracle.

Unfortunately, this is the wrong approach if you happen to want those carriage
returns as part of the data stored in Oracle.  If any strings that you
write to Oracle contain carriage returns, you must apply the following
workaround to avoid corrupting your data.

Workaround

The bug was introduced with the addition of a new method called GsOracleConnection>>prepareSqlString:.
This method replaces any carriage returns with spaces, and also converts
a DoubleByteString to a String if possible.

Replace the method GsOracleConnection>>prepareSqlString: with the following
code, which retains the DoubleByteString conversion, but removes the code
that replaces the carriage returns with spaces:

---------------------------------------------------------

category: 'Temporary 39531 Fix'
method: GsOracleConnection
prepareSqlString: sqlString

" Do some pre-processing of a SQL command string
  to make sure it complies with various Oracle restrictions:

  * No DoubleByteStrings ( try converting to String )
  * [code to replace carriage returns removed]
"

   | str |
   sqlString _validateClass: String.
   str := sqlString asString copy.
   " At this point, we shouldn't still have a DoubleByteString "
   (str isKindOf: DoubleByteString)
      ifTrue: [ str _errorExpectedClass: String ].
   ^ str
%


                

Last updated: 4/9/14