Commented by: @asfernandes

Didn't it has been decided that all strings passed in DPB are like filename strings, so now #⁠#⁠ would be required?

Commented by: @hvlad

I don't remember such decision.

It is obviously not backward compatible. You can find real-life example there

http://tech.groups.yahoo.com/group/firebird-support/message/107621 (archive)

Commented by: @asfernandes

README.connection_string_charset.txt (and supposedly in release notes too):

... That's accomplished using the symbol #⁠. It is a prefix for an Unicode code point number (in hexadecimal
format, like U+XXXX notation). You should write it in this way: #⁠XXXX with X being 0-9, a-f, A-F.
If you want to use the literal #⁠, you could use #⁠#⁠ or #⁠0023 (the code point number for it).
That character is interpreted with this new semantics at the server even if the client is older
than v2.5.

...

Updated for 2.5 Beta 2: 2008-07-11

These rules are now valid for string DPB items too.

Commented by: @asfernandes

Rationale for the second change is in thread "Non-ASCII names for users and roles".

Commented by: @AlexPeshkoff

Looks like this solution caused some unexpected results.
I suggest to:
1. In client starting with 2.5 (PROTOCOL_VERSION12) add automatic replacement of single #⁠ in username with #⁠#⁠ if there is no valid sequence after it.
2. For older clients connected to server do not perform username unescaping at all.

Commented by: @asfernandes

What is "single #⁠"? Why do you want to validate the string only if ends with "#⁠"? "#⁠" is used with follow letters/numbers.

What a good time to discuss that again. We lost 2 or more months with this already. Now we should release 2.5.

It has well know that DPB strings with #⁠ has needed to be modified to that work. Now because *one* guy that didn't read the release notes found a "problem" we should change what has already been validated to work as designed?

Actually, I can find others backward incompatibilities already in the tracker that deserves attention.

Commented by: @hvlad

About README.connection_string_charset.txt
a) such small note obviously is not enough to describe such valuable change
b) it is very confusing that note was added (2008-07-11) before document was created (2008-12-15) :)

About thread "Non-ASCII names for users and roles"
a) thank you that you for not pointing me *when* it was started. it is big pleasure for me to search archives
b) the change have (not discussed) side effect, it happens. it should be fixed, imho
c) i found also CORE2551, it have perfect explanations, thanks again

Commented by: @hvlad

Another bug

SQL> create database 'S:\Temp\abc#⁠xyz\x.fdb';
Statement failed, SQLSTATE = 08001
Invalid connection string
-Invalid ESCAPE sequence

Commented by: @hvlad

Well, after Nth reading of README.connection_string_charset.txt and some code i see that code corresponds documenttaion (while some comments will not make harm there). But i still think that assumption that all strings in non-UTF8 DPB could contain escaped unicode letters (and every #⁠ is doubled) is wrong. Let me show why i think so.
By new rules application should duplicate #⁠ symbols in connection string if it connects to the FB 2.5.
But if application connects to the pre FB 2.5 it should not duplicate #⁠ symbols.
Application can't know what server version it connects to before connection is made !

Commented by: @dyemanov

Perhaps a new DPB tag e.g. isc_dpb_escaped to explicitly specify when the input DPB item contains escaped strings would be a good solution. With the same backward compatibility rules as for isc_dpb_utf8_filename (documented in the readme), it would resolve the issue. The problem here is that using escaped strings would be nearly impossible without recompiling the application (to benefit from the new DPB tag).

Commented by: @hvlad

Additional clause for CREATE DATABASE and CONNECT statements also required for script utilities such as isql

Commented by: @helebor

And the SPB would have to implement it also.

Commented by: @hvlad

Will we do something with it in 2.5.0 ?

Commented by: @AlexPeshkoff

Looks like we have 3 choises:
1) Leave as it is now.
2) Roll back changes, causing it, completely.
3) Try something more intelligent - for example, add isc_dpb_escaped (almost impossible without application rework) or may be try to catch an exception and automatically add second #⁠ case when there is no correct UTF symbol's code found. If user really wanted to add UTF symbol, this will hardly make reasonable login or filename, i.e. he will get error a bit later. But for cases when password had #⁠ symbol (quite possibel case) this will definitely help.

Commented by: @asfernandes

I'd say there is two options only:
1) Leave it
2) Rollback changes related to #⁠

3 does not make sense for me, it's not something that can be analyzed.

Also, we must pray for one that didn't read the release notes start saying again that UTF8 conversions from client/server (also documented) are bug because is different than what was happening in previous versions.

Commented by: @hvlad

I see following options
a) remove it
b) introduce isc_dpb_escaped\isc_spb_escaped and add support for corresponding SQL statements
c) disable it in 2.5.0 and implement (b) in 2.5.1

PS And pray that one who created features worries about backward compatibility. Bug, even properly documented in RN, is still a bug ;)

Commented by: @dyemanov

I'd suggest to disable (comment out?) the escaping code until we can provide this feature without affecting backward compatibility. If it could be done for v2.5.1, let it be so, but let's please release v2.5.0 without this issue.