Sybase SQLAnywhere 5.0 for NT bugs

Sybase SQLAnywhere 5.0 for NT bugs

Post by Roedy Gree » Mon, 16 Nov 1998 04:00:00



Sybase seems to want you to pay THEM to accept bug reports.  Symantec is
the same way.  I am rather ticked with this attitude.  The vendor has sold
a defective product and refuses to ever listen to the complaints.  This is
not the same as requesting support.  When you report bugs you are doing
them a favour.

(1) If you create a large people database and index by a secondary index
postalCode, you can do very rapid searches with SQL of the form: SELECT *
FROM PEOPLE WHERE POSTALCODE BETWEEN 'V5H0A0' AND 'V5H9Z9';  However if you
add an ORDER BY clause of any kind the search will take an EXTREMELY long
time, even if you select only a couple of records.  From the PLAN presented
which says it is building a temp table based on POSTALCODE, I think the
fool thing is searching the ENTIRE POSTALCODE index from beginning to end,
or is reading the entire database beginning to end.  Even when I give it an
estimate of 1% it does the same thing. It should simply scan that little
section of the POSTALCODE index spin off the people records it finds and
sort.

(2) with the -b option on dbeng50 I found many times that even after a
COMMIT-WORK, when I restarted the database, my last actions were not there.
I have not nailed down precisely when this happens.  I suspect it may be
related to running out of RAM.  I found I could bypass the problem by
loading data then building indexes rather than setting up indexes and
loading data.  Building indexes one by one later requires less RAM (and it
turns out is faster even though it takes many passes through the data).

For the JAVA GLOSSARY and the CMP Utilities: <http://mindprod.com>
--
Roedy Green,  Canadian Mind Products
-30-

 
 
 

Sybase SQLAnywhere 5.0 for NT bugs

Post by Roedy Gree » Tue, 17 Nov 1998 04:00:00


Roedy Green asked, wrote, or quoted:

Quote:

>(1) If you create a large people database and index by a secondary index
>postalCode, you can do very rapid searches with SQL of the form: SELECT *
>FROM PEOPLE WHERE POSTALCODE BETWEEN 'V5H0A0' AND 'V5H9Z9';  However if you
>add an ORDER BY clause of any kind the search will take an EXTREMELY long
>time, even if you select only a couple of records.  From the PLAN presented
>which says it is building a temp table based on POSTALCODE, I think the
>fool thing is searching the ENTIRE POSTALCODE index from beginning to end,
>or is reading the entire database beginning to end.  Even when I give it an
>estimate of 1% it does the same thing. It should simply scan that little
>section of the POSTALCODE index spin off the people records it finds and
>sort.

I am pleased to report this is fixed in Sybase SQL anywhere 5.5.04.  You
can get the upgrade at www.sybase.com.  The new version is blinding fast at
this type of query.

For the JAVA GLOSSARY and the CMP Utilities: <http://mindprod.com>
--
Roedy Green,  Canadian Mind Products
-30-