Our experience with maxdb

> Dear MaxDB community member,
>
> We have started a process to gather stories around MaxDB usage in the
> community: Please tell us about your MaxDB experiences or plans! 

Hello maxdb-Team,

we are using sapdb (Version 7.4.3.32).

In standard cases maxdb works very good.
But for professional application scenarios, there are some 
VERY CRITICAL Problems:

1. Bad Deadlock-Detection: 
  Deadlocks caused by tab_share locks combinded with row-Locks
  are not detected at all. Not even very simple cases!

2. Bugs in the Lockingmechanism:
  under some circumstances a simple SELECT statement 
  is capable of keeping LOCKs(!!!).
  This means that an application !MUST! commit after only 
  sending SELECT-Statements.

3. Many many problems with OUTHER JOINS:
  A)
    SELECT * FROM T1 
    LEFT     JOIN T2 ON T1.X=T2.X 
    WHERE    T2.ABC=1 OR T2.ABC=2
    (This simple SQL gives back wrong results, Problem is the OR !!!)
  B)
    SELECT * FROM T1
    LEFT     JOIN T2 ON T1.X=T2.X
    LEFT     JOIN T3 ON T3.Y=T2.Y
    (Wrong results, Problems with T3.Y=T2.Y, because T2 and T3 are OUTHER Join Tables) 
  C)
    Problem sometimes with HAVING:
       SELECT ....
       LEFT JOIN ...
       GROUP BY ..             -> correct results
    same sql with 1=1:
       SELECT ....
       LEFT JOIN ...
       GROUP BY .. HAVING 1=1  -> SOMETIMES WRONG RESULTS!!!

4. Problems with the Kernel: 
  - DB doesnt restart after Powerfailure
  - Kernel crashes...
  - Problem with log-files... etc 
  (see the Mailinglist, it represents our experiences)

5. Broken Python driver with many stupid bugs
  like Referencecounting, free(NULL) bugs, ...etc (only some were fixed until 
now)
  My patches that I sent were only applied sometimes
  to the source tree.

6. SQLDBC could not be compiled because of a broken 
  version on the Downloadserver.
  (Got some hints from the mailinglist, but nothing really happens)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
We are thinking about if we should switch
a) from sapdb 7.4 to maxdb 7.6 or
b) from sapdb 7.4 to an other DB like Oracle or MSSQL
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Our problem is that cost of the time our programmers spend with
the bugs of maxdb is too high.


Our conclusion:  (Refers to Version <=7.4.3.32)
- For small applicaitons with less concurrent write access 
 maxdb is a good choice. 
- For bigger applications with complex table structures
 (>40 constrainted tables with highly concurrent access)
 the time for finding deadlock causing parts in the software,
 or testing different versions of SQL queries (to workaround SQL-Bugs)
 is too high!!!

Suggestions:
- Solve the worst bugs before adding new features:
 (Our) priority list:
  1. Kernel stability
  2. SQL-Bugs
  3. LOCKING and DEADLOCK bugs
  4. Driverbugs


Greetings, and thank you very much for the
good support in the mailinglist in 95% of all caes,

Andre' Reitz

--
__________________________________________________________________________

Als Technologieunternehmen konzipieren und entwickeln wir maßgeschneiderte 
Feedback- und
Monitoring-Systeme - wie beispielsweise Lösungen für Beschwerde- und 
Ideenmanagement.
Mit dem Inquery® Survey Server bieten wir eine der leistungsfähigsten 
Standardlösungen für
Online-Umfragen mit dem Schwerpunkt auf der Messung von Kundenzufriedenheit an.
__________________________________________________________________________


Inworks GmbH
Andre Reitz, Leiter Entwicklung
Hörvelsinger Weg 39, 89081 Ulm, Germany
Tel +49 (0) 731 / 93807-21
Fax +49(0)731/93807-18
Internet: http://www.inworks.de



--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx