|
History
| Log In
|
|
|
|
Hi Kevin,
I believe this is problem with MaxDB in that you can not use the LIKE operator on a LONG field. Out of curriosity, what are the reasons for using MaxDB. We don't have too many customers on that. Cheers, Thanks Nick, I just seen the error and figured I would post it since it could likely cause something that should be found to not be.
Our discovery of MaxDB came when it was still sapdb due to our adoption of a CRM package. At the time it was the only well backed (SAP) open source DB with triggers, procedures, etc. and SAP uses it as there backend for budget SAP R/3 implementations which made the decision for us to use it pretty easy. I would (and still do) have liked to have used PostgreSQL since it seemed to perform better at the time but I'll save that conversion for when I have nothing else to do. MaxDB does have its quirks but it is solid and gets the job done just as well as any commercial DB on the market. Ours is ran on a 64 bit MP AMD Opteron and is extremely fast. We have MS SQL v7 on a 32 bit MP machine with more processor juice than the Opterons but MaxDB will smoke MS SQL. Lets see if we can make this work on MaxDB.
Just an FYI,
The field is a LONG ASCII and is treated like a TEXT/IMAGE field is in MS SQL. You cannot use the LIKE operator in MS SQL on TEXT fields either so this is not a strange thing. Hi Kevin,
I have reproduced your error using maxDB 7.6. After hunting around for a bit I can not find a solution to this problem with maxDB. The issue is that we need to store the information in a very large text field, descriptions can be extreamly large. MaxDB offers us a varchar which caps-out at 8000 characters (for ASCI, 4000 for unicode), this is too small. The next thing up is what we are using, a LONG VARCHAR which caps-out at 2gig, which is good, but as they say "LONG columns cannot be compared to one another. The contents of LONG columns cannot be compared to character strings or other data types.", which is bad. You can read about the LONG VARCHAR here  if you are interested.
The good news is that we only perform this kind of query once within JIRA, in the QuickSearch. Furthermore this will only ever effect you on issues that have been moved from their original project to a new project when you are searching on the issue key from the original project. This should not be a huge loss of functionality, but I am sorry that I can't see a way to fix this up for MaxDB. Thanks, Hi Dylan,
Yes I am well versed on the long varchar limitations in sapdb (it has been giving me headaches for years now) and I figured it was unlikely you could do anything about it for 7.5.x versions but the 7.6.x series now contains specific functions that allow you to operate on a long varchar field. Maybe you can bookmark this for later down the road once the 7.6.x series of MaxDB is the most commonly used version and put in specific hooks that will allow the operation to succeed. Thanks for looking into, don't ya just love MaxDB....lol. Kevin,
Thanks for the feedback! May I ask how "special" these operations are? Is it as simple as using a diffrent comparison operator (I bet not)? Or are there MaxDB specific built in functions that do can be used? Anton No it isn't an operator but rather just the LENGTH( ) and SUBSTR( ) for LOBs.
Here I'll give ya the link for better reference... http://dev.mysql.com/doc/maxdb/intro_76.html
Thanks for the pointer. That was what I was afraid of
 At the moment we do not use db specific functions. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Minor
MaxDB has issues with using LIKE on a LONG field
Which database are you using here?
Cheers,
Jeff