Dear Peter and Francisco!
But the filters must be same. We used many range filters in text fieds.
Firstly: sorry for name change. I might read too many about Totti or I was listening too many "Vamos a la playa" spanitaliano disco... :-) :-) :-)
To better understand my problem I write about the background.
We used different database engine "before" PG, and more codes based on that SQL.
Because now only 70-80%% migrated, we need to preserve the compatibility with older database engine.
This run on Windows, and it uses the local collation order (ANSI: the basic ASCII extended with HUN characters. Like ISO-8859-2, or Windows1250).
It uses Windows comparison, so it doesn't matter that client sort or the server - in Hungarian machines it's same (AnsiCompareText/Str).
We dont't need to worry about filters/orders.
All ASCII characters preserved in sort, but Hungarians inserted between ASCII...
English: A, B, C, D, E, F,
Hungarian: A, Á, B, C, D, E, É, F
The data export works same in MS Excel or Libreoffice. The filters are same.
I supposed that HU_HU collation mostly similar.
The whole thing is important in row filtering, not in order. For sort data we can use Devexpress grids.
But the filters must be same. We used many range filters in text fieds.
With older engine we can safely search ranges with "Á16-00023", "18343843/BÉR" values, the result row number is same in programme side and f. e. in Excel side.
I didn't understand what a hell caused this problem in PG side, what I did wrong.
This is why I showed many demonstrations, because I wanted to understand. The simulations points to "symbol removal".
This is why I showed many demonstrations, because I wanted to understand. The simulations points to "symbol removal".
Yes, we may handle these problems, but we need to construct "compatible" SQL, or we need to make different solution in PG side.
This would cause "bugs" in the working applications, and make difference between two products.
This would cause "bugs" in the working applications, and make difference between two products.
The C collation is good for only numbered fields.
Splitting to substring and order on them is also good in this example.
Splitting to substring and order on them is also good in this example.
But for special accents (, "ű", "ó", "ő", etc) we need to use different solution...
And the text fields are free, so "/" is only one symbol they can use.
And the text fields are free, so "/" is only one symbol they can use.
Thank you for your instructions, help, and "flame"... :-)
Have a nice day for you!
dd
