clu->mhatheoo: where is the bug? means: why it should be case-unsensetive? you
can connect both filter condition with an 'or' statement to get this result

=> works as designed

=>clu

oops, this seems to be sort "you did not understand what I ment". Okay, can
happen, but before we play ping-pong in here it would be very kind, if you leave
this issue open until  it had been discussed for a little.

yes, you are right, it works as designed, which is at actual the problem.

"OR" is no working condition to destinguish between upper- and lower case.
so that needs to be solved in another way when setting the parameters to the
filter. But which? 

Anyway, it is no really good idea to make sql-queries to destinguish between
upper and lower or mixed field-content. ANSI will work in another way.

Reopend and awaiting your advice

Martin

clu->mhatheoo: i do not want to be unkind .. but this is the issue tracker and
neither a discussing board nor support center, so please write a precise
described feature enhancement after you have discussed your ideas/problems on a
corresponding mailing list/newsgroup f.e. users@dba f.e. here:
http://dba.openoffice.org/servlets/ProjectMailingListList

thx

=> close

Created attachment 51095 [details]
mini-table with two queries - one using upper()

well Christoph 

I feel a litle disapointed about not reading my prior comment.

However:
The following phrase can not be entered in the assistant-modus of OOO,
but easyly in the sql-modus

SELECT * FROM "mhtabelle1" WHERE ( ( UPPER ( "Feldtext1" ) LIKE 'A' ) )

This is the solution to make a query case-insensitive(if you query on
non-indexed fields.
You need to find a solution for that
As this is a DBMS for the masses - like me - the default behavoir needs to be
"upper" as the default at that place.

if you need something to play with you find my sample odb attached

Martin


P.S.:
what did you ment with "this is not a support center"? When expected things do
not happen as expected, it is a defect-by-design - even if you have a workaround.

Using the HSQLdb engine supplied with Base one can define fields of type
VARCHAR_IGNORECASE - in this situation the case of characters is stored in the
table ( so Mrs Jones stays Mrs Jones ) but all comparisons are performed without
regard to case. This includes the form based filters. So there is already a way
to achieve the results you are seeking.

I am setting this issue therefore to WORKSFORME

=> atj

well, this is no solution for the problem, and I am not sure whther you really
got the problem:

The case is about tables, that already exist, and for these, not the HSQLB
itself but the front-end/integration from OO is behaving wrong. 
The solution is as stated before and can be done within a SQL-statement only.
Wihin ANSI-SQL indexed fields should always be treated case-unsensetive, while
sorting or using as temporary-index on un-indexed fields should be
case-sensetive. That are rules. But as OO-Base is not using indexes on
DBase-files, every field in a query is - sofar - treated case-sensetive. 

my proposal was, that OO should work the other way round and treat fields
case-unsensetiv by default.
However - no solution for DBASE-files - I reopend the issue.

Martin

Respecfully - you are confusing the issues here - or maybe I am.

Whether the comparison is performed in a case sensitive or case insensitive
manner is dependent on the database engine used and how it has been configured.

So where Base is using HSQL, MySQL, Postgres, SQl Sever... this is a non-issue
from the UI perspective, as it passes the select statement to the engine and
consumes the results.

However - it may be that you are limiting this to dBase files and if that is the
case then I would suggest that you update the summary line and mark the issue as
a request for enhancement - ( yes it is really a change in behavior but all the
same that is how I would suggest you do it )

if anything work as designed and a single person do not like it, he (in this
case you) can discuss it in the mailing list to 'push' the change idea ..
because the issue tracker is not the right place and you do not get the proper
attention for you problem .. the second way is to write a feature enhancement
for this topic (then everybody can vote for)

do not want to blame you, but this is the way it works on oo

thx

=> close

well christoph, I am not sure, whether this issue will need to be opend
immidiatly - or later. I will have a look.

So, where are the points:
I guess it would be a good idea if you look up, how ANSI-SQL is intended to work
- and in that you will find out, that handling of indexed and non-indexed fields
is different, which it is not in OO.o (but in HSQL, as I understood)

And dispite of that - my complaint is not about how I get a workaround - that
was found by me - but whether the BASE-part is having the features that it is
agreed to have - and that you can find in the help-files for example. Note, we
are not talking about defects by design - these we have too - we are talking
about not being implemented what is agreed - and state of the art.
 
However, you shouldn't have closed this issue, because VARCHAR-Ignorecase is no
option within the last stable (241) - you can see that from the assistent only -
and there is at actual neither the CWS named where its integrated nor a working
beta available, so it is not working yet.

keep it closed,  I will recheck it with the next available beta and than leave
it closed or reopen it again.

Martin