Writing this WAY after it actually happened:

The conference this year was at Atlanta. It was hosted by both the Association of REALbasic Professionals and REAL Software. Great location next to the Airport. There was a call for speakers and I was jokingly entered, and ended up speaking about Serial devices and Barcode Printing using REALbasic. There were announcements by Geoff Perlman, the CEO of REAL Software. He went through the up and coming features of REALStudio as well as the Web components. There were numerous topics that were covered, all of which were very interesting. Overall, a fantastic trip.

[View with PicLens]

Written by Milton Lai

We migrated several databases across from ASE 15.0.2 to a new sybase server over the weekend. All went well until this morning when we found out that the like operator wasn’t behaving as expected. Instead of the percent/mod operator representing this definition: “Matches any string of zero or more characters.”; it became “any string of one or more characters”.
For example:

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.

Just re-encountered this issue. If you have a table where there is an attribute of type varchar(2000) for instance (really just anything greater than 255), when you pull it out using sybase_connect, it will only return 255 characters. This is outlined as a bug on php.net. To get around this issue, use a convert to text or update the attribute to be of type text if you can.

select convert(text, reallybigvarcharattribute) from table

Written by Milton Lai

I’m currently setting up a new server to play with and apart from the usual nightmare of compiling everything and finding all their dependencies and what not, I did hit an issue which I couldn’t find a clear answer online for. I used the following to configure PHP 5.3.2:

./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

We just recently hit the following error from Sybase:

“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.