[Firebird-devel] [FB-Tracker] Created: (CORE-6202) External table file names not transliterated to OS character set
External table file names not transliterated to OS character set Key: CORE-6202 URL: http://tracker.firebirdsql.org/browse/CORE-6202 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.4 Environment: Windows 64 bit with OS character set Windows-1252 Reporter: Kjell Rilbe Priority: Minor It seems that the file name specified for an external table is sent to the operating system's file operations without transliteration. This makes it impossible to use file names with non-ASCII characters. For example, specifying the file name 'Teståäö.txt' will result in a file named 'Teståäö.txt'. Which is the Win-1252 interpretation of the byte sequence that UTF-8 string 'Teståäö.txt' is encoded as. In other words, it would appear that the file name, stored in UTF-8 (UNICODE-FSS?) format is sent as is to a Windows system call that expects the file name to be encoded in the operating system's codepage, in this case Win-1252. I've tried this in both isql and FlameRobin and got consistent results. The file name appears correct in RDB$RELATIONS.RDB$EXTERNAL_FILE but ends up wrong in the operating system, like described above. I expect this to be rather easily fixed, considering the file name is always stored in the same character set (UTF8, or is it UNICODE_FSS?) and the operating system's character set is known. All that should be needed is to add transliteration of the stored file name before sending it to any operating system call. By the way, I think I've had similar issues with database file name, but have not tried it recently. Maybe it would be a good idea to go through all operating system file operations and make sure the file name(s) passed are properly transliterated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] IResultSet and IStatement releasing
On 04/12/2019 17:59, Jiří Činčura wrote: > Hi, > > do I have to call IResultSet::close and IStatement::free if it's immediatelly > followed by calling release method? > close/free already calls release, so no, unless you had called addRef, you should not call both. But I have a preference to call close/free instead release. The former will really destroy the resource (but not necessary the memory allocated by the object - if it has more refs) and the later just decrements a reference (and destroy the resources and memory if it has no more references). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] IResultSet and IStatement releasing
Hi, do I have to call IResultSet::close and IStatement::free if it's immediatelly followed by calling release method? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ODP: CORE-6199 - few question about Firebird 4
>> IMO, it will be much better if you describe the task you need to solve Task is in CORE-6199 but i need only part of it. My current solution is with OAT + RDB$RECORD_VERSION and now i am looking into FB4 changes if it can help more. It is better now because of existence of RDB$GET_TRANSACTION_CN. But it still do not use and index to query. And my question was about optimize this part to use an expression index somehow. Regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-6199 - few question about Firebird 4
03.12.2019 10:04, liviuslivius wrote: Vlad, currently this query cannot use and index SELECT o.* FROM orders o WHERE RDB$GET_TRANSACTION_CN(o.RDB$RECORD_VERSION) > your_last_queried_CN; also creating expression index is not good here as CN is not stable. What if CN will be written into database master page and not reset after last connection from database? Same as currently transaction ID. > Also instead of only memory list of CN pair with transaction id it will be written into DB. I know more disk writes, but this will be same as for TIP already or not? It will kill performance. IMO, it will be much better if you describe the task you need to solve instead of offering a way you think you can use to solve it. Probably it could be solved in a different way without need to introduce new global bottleneck. Regarsd, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6201) Trailing spaces in varchar in where
Trailing spaces in varchar in where
---
Key: CORE-6201
URL: http://tracker.firebirdsql.org/browse/CORE-6201
Project: Firebird Core
Issue Type: Bug
Components: Charsets/Collation
Affects Versions: 3.0.4
Reporter: Alexander Muylaert
Priority: Trivial
Hi
I really was not expecting this statement to be true. As I understand it,
trailing spaces are ignored at all levels. But I cannot think of any good
reason why this is what it is. I noticed ms-sql has it as well.
select cast('dog ' as varchar(200)) = trim(cast('dog ' as varchar(200)))
from RDB$DATABASE
Thanks for answering
Alexander
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
