[View with PicLens]

Written by Milton Lai

select firstname from person where firstname like 'paul%'

This query would, in versions prior to ASE 15.5, return a list similar to the following:
paul
paulie
pauline
In ASE 15.5 though, you’ll get the following:
paulie
pauline

This threw off our applications completely. Sybase technical support did manage to confirm that it was a known bug, which is fixed in 15.5 ESD#1 17791. In the meantime, he suggested we call the following command on the database to work around it until we find the time to do the update:

dbcc traceon(7739)

There was only one link online which really let us know that it could be Sybase’s fault rather than a simple parameter, being the sybase.public.ase.general group on google.
This was all run on a Sun Solaris SPARC server:

select @@version

Adaptive Server Enterprise/15.5/EBF 17336 SMP/P/Sun_svr4/OS 5.8/ase155/2391/64-bit/FBO/Tue Nov 10 01:27:55 2009

This is a quote from an email I received from a Sybase Technical Officer ( this is not official in any way):

CR#616224-WRONGRES % wildcard is not matching 0 characters (i.e. end of string)
Details:
Like pattern matching may return fewer rows when the following conditions are met:

1. server’s default sortorder is non-binary single-byte sortorder

2. like pattern is a constant literal

3. like pattern string length is the same as column data length

4. column is either varchar or char


Workaround:

1. remove ‘lig =’ lines in the .srt file if ligatures are not used, this will then require
a sort order change and accompanying steps.

or

2. enable ‘statement cache’ and enable literal parameterization of literals in the LIKE
clause with traceflag 7739. Certain statements such as ‘select into’ will not benefit
from this workaround.


This bug was fixed on 15.5 ESD#1, 17791.

select convert(text, reallybigvarcharattribute) from table

Written by Milton Lai

./configure –with-apxs2=/usr/local/apache2/bin/apxs –with-gettext –with-zlib –with-jpeg-dir –with-png-dir –with-ldap –with-openssl=/usr/local/ssl –with-curl –enable-exif –enable-ftp –with-gd –with-xsl –with-libxml-dir –with-libxml-dir –with-gd –with-sybase-ct=/home/sybase/sybase64/OCS-15_0

This worked a treat, but it was when I called “make” that the following appeared.

	ld: fatal: library -lcomn: not found
	ld: fatal: library -lct: not found
	ld: fatal: library -lcs: not found

The first approach I had was to edit the Makefile that configure creates to change lcomn to lsybcomn, lct to lsybct and lcs to lsybcs. You should be able to notice that within your sybase/OCS-15_0/lib folder, there are files which reflect the later name changes – libsybcomn.so .
This worked. I then was told (since it was scribbled on a piece of paper somewhere) about sybase/OCS-15_0/scripts/lnsyblibs which creates softlinks with the expected library file names. So now there are a bunch of files looking like libcomn.so -> libsybcomn.so .

Written by Milton Lai

“There is insufficient heap memory to allocate -1562977772 bytes. Please increase configuration parameter ‘heap memory per user’ or try again when there is less activity on the system”

when trying to get the results out of Sybase as xml using the “for xml all” function. It works fine normally, until your result sets hit over 500 rows or so. This is due to the heap memory space which most people would be reluctant to change – the query returns your data, by default, as one big row and normally of type TEXT. To get around this, “for xml option “incremental=yes root=yes”" will set each row of results as a separate row coming back. This means that instead of a huge chunk of TEXT coming back, it’ll appear like a normal record set, but instead of the normal data, it’ll appear as xml data.

For more information on XML for Sybase head to http://manuals.sybase.com/onlinebooks/group-as/asg1251e/xmlb/@Generic__BookTextView/4521. The following section is taken from that page and helps explain the “incremental” option.

The result set that a for_xml_select statement returns depends on the incremental option:

incremental = no returns a result set containing a single row and a single column. The column datatype is text. The value of that text column is the SQLX-XML representation of the result of the basic select statement. This is the default option.

incremental = yes returns a result set containing a row for each row of the basic select statement. If the root option specifies yes (the default option), an initial row specifies the opening XML root element, and a final row specifies the closing XML root element.

For example, these select statements return two, one, two, and four rows, respectively:

select 11, 12 union select 21, 22
select 11, 12 union select 21, 22 for xml
select 11, 12 union select 21, 22 for xml option "incremental=yes root=no"
select 11, 12 union select 21, 22 for xml option "incremental=yes root=yes"

Written by Milton Lai.