We apologize for the misunderstanding, we dont't want to frighten developers that work on maxdb saying that it is unstable. We aprreciate your effort to support us. Our previous mail was just a consideration about some problems we are encountering, and trying to solve with your help.
We'll submit to you our possible further problems with full details. Thanks Fabio ----- Original Message ----- From: "Zabach, Elke" <[EMAIL PROTECTED]> To: "'Fabio Pinotti'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, June 11, 2004 3:57 PM Subject: AW: Maxdb considerations > Fabio Pinotti wrote: > > > > Dear staff > > we are porting a complex j2ee/Oracle enterprise application to a MaxDb > > database, but we have found several problems. > > We started using 7.5.00.12 installed on a linux machine, then we have > > updated to 7.5.00.14. > > It seems that database is very unstable: it crashes for a lot of reasons: > > calling query statements, calling user defined functions inside sql > > queries, and so on... > > > > We have a complex package in Oracle environment, used to check users > > permissions on documents, activities, etc.: it is made of lot of nested > > functions. > > We are trying to translate it into internal maxdb syntax, but we have been > > founding several troubles; for example: > > 1) we call a function with 3 params, the function calls onother one > > passing two of them; when the second function returns, parameters are not > > valid (they are re-initialized) > > 2) even if functions are succesfully compiled, db crashes at run time (we > > have to manually restart db!!) if they contain type mismatch (like: int to > > number) > > 3) recursion seems to be not possible > > > > On the other hand, we are trying to use existing sql (that runs on Oracle > > db): we see that maxdb has the "oracle mode", but we often encounter > > problems with types: maxdb seems to be less flexible than oracle. The main > > issue is that calling such a query causes the database to crash. > > Moreover, we often have to use workaround (swapng parameters in decodes, > > using dummy substr(), etc,...) > > > > We don't undertstand what's wrong with our approach, and we would like to > > know if the present release of maxdb is stable. Our goal is to develop a > > fully open source solution, but considering all of these problems, we > > aren't sure that maxdb is the right choice for our purpose. > > Did I miss something? > Joannes Capitanio and you sent us three topics: > 1. ADDDATE and value causing an error where noone should be returned (we are working on it) > 2. a question about recursive functions > 3. the problem with the very important feature DECODE (?, ...) (workaround given, fixed with the next version) > No crash, no info about problems with int <--> number, functions called in functions and so on. > As we always say if we are asked: functions in 7.5.00.* are on your own risk. We do not like the idea of crash in that context, but we are not able to put much effort in this topic in this release. > > We do what we can to produce a stable version and those problems we are told a little bit more precise will be handled as fast as possible, especially to avoid crashes. But please do not spread the idea of 7.5.00.* being a very unstable version. That is, as far as I know, not the impression other users have. Yes, there are bugs in (unfortunately), but only if we are given a chance to fix them (by describing them as precise as possible, sending vtrace / data sometimes, and so on) we will be able to increase the stability of the next versions (much more than only relying on our own checks, which are finding problems as well). > > Elke > SAP Labs Berlin > > > > > > Thanks in advance > > Best regards > > > > Fabio Pinotti > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
