Ubuntu Locale
-
Key: CORE-5288
URL: http://tracker.firebirdsql.org/browse/CORE-5288
Project: Firebird Core
Issue Type: Bug
Components: Charsets/Collation, Engine
Affects Versions: 3.0.0
Environment: Ubuntu
> AFAIK, it's not. And I don't see how it can happen in the code.
I'm sending the isc_info_firebird_version, isc_info_end only in
op_info_database. And the buffer I get back is:
103, 74, 0, 2, 28, 87, 73, 45, 86, 51, 46, 48, 46, 48, 46, 51, 50, 52,
56, 51, 32, 70, 105, 114, 101, 98, 105, 114,
21.06.2016 19:58, Dmitry Yemanov wrote:
> AFAIK, it's not. And I don't see how it can happen in the code.
AFAIR, each layer adds its own version to the result, so it is engine
version + Y-valve
version or remote Y-valve + local Y-valve.
--
WBR, SD.
21.06.2016 19:48, Jiří Činčura wrote:
>
> when I ask for isc_info_firebird_version (currently on FB3) it looks to
> me I get response for isc_info_isc_version followed by
> isc_info_firebird_version together. Is that expected?
AFAIK, it's not. And I don't see how it can happen in the code.
Hi *,
when I ask for isc_info_firebird_version (currently on FB3) it looks to
me I get response for isc_info_isc_version followed by
isc_info_firebird_version together. Is that expected? Maybe it was some
compatibility shim.
I.e. for isc_info_firebird_version on FB3:
length: 76
manually
On 06/20/2016 06:53 PM, Jiří Činčura wrote:
> Can this be somewhat requested also by isc_info_firebird_version or
> similar?
>
This is requested by isc_version() in legacy API and
IUtil::getFbVersion() in new one.
--
