Commented by: @dyemanov

Please test prior version(s) and specify whether it's a regression or not.

Commented by: @pavel-zotov

On WI-V2.1.7.18553 and WI-V2.5.5.26907 both cases produce exponent with three digits (i.e. with leading zero), regardless to used protocol:

C:\1INSTALL\FIREBIRD\fb25sC\bin>.\isql -q
SQL> set sql dialect 1;
SQL> create database 'c:\temp\tmp25_d1_local.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+019

SQL> quit;

C:\1INSTALL\FIREBIRD\fb25sC\bin>.\isql -q
SQL> set sql dialect 1;
SQL> create database 'localhost/3255:c:\temp\tmp25_d1_remote.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+019

SQL> show version;
ISQL Version: WI-V2.5.5.26907 Firebird 2.5
Server version:
Firebird/x86/Windows NT (access method), version "WI-V2.5.5.26907 Firebird 2.5"
Firebird/x86/Windows NT (remote server), version "WI-V2.5.5.26907 Firebird 2.5/tcp (balaha)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.5.26907 Firebird 2.5/tcp (balaha)/P12"
on disk structure version 11.2
SQL>

Commented by: @dyemanov

v2.х uses the XNET protocol in this case, not embedded like v3. You may try running fb_inet_server with the -i switch to disable XNET and check again.

Commented by: @pavel-zotov

Result is the same.
I've changed ImagePath string in the registry for FB 2.5 service, it looks now like this:

C:\>sc qc FirebirdServerfb25sC | findstr /i /c:path
BINARY_PATH_NAME : C:\1INSTALL\FIREBIRD\fb25sC\bin\fb_inet_server.exe -s fb25sC -m -i

-- and then restart FB and repeat commands mentioned above.

Output is:

C:\1INSTALL\FIREBIRD\fb25sC\bin>isql -q
SQL> shell del c:\temp\tmp25_d1_*.fdb;
SQL> set sql dialect 1;
SQL> create database 'c:\temp\tmp25_d1_local.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+019

SQL> quit;

C:\1INSTALL\FIREBIRD\fb25sC\bin>isql -q
SQL> shell del c:\temp\tmp25_d1_*.fdb;
SQL> set sql dialect 1;
SQL> create database 'localhost/3255:c:\temp\tmp25_d1_remote.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+019

Commented by: @asfernandes

Cannot reproduce in Linux.

Commented by: @hvlad

I confirm that embedded on Windows produced 2 digits in exponent while standalone server produced 3 digits.
This is related with CORE1171 which goal was to "make floating point's exponential format the same across platforms" (this is original desription of the ticket).
So the questions is:
- how many digits in exponen is printed on Linux currently ?
- should we move _set_output_format() call from isql into engine ?

Commented by: @pavel-zotov

> - how many digits in exponen is printed on Linux currently ?

Currenlty one may see always *two* digits, regardless of protocol.

$ /opt/fb30sc/bin/isql -q
SQL> set sql dialect 1;
SQL> create database '/var/db/fb30/tmp20151104_1645.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+19

SQL> quit;

$ /opt/fb30sc/bin/isql -q
SQL> set sql dialect 1;
SQL> create database 'localhost/3330:/var/db/fb30/tmp20151104_1646.fdb';
SQL> select cast(1e19 as varchar(30)) from rdb$database;

CAST

1.000000000000000e+19

SQL> show version;
ISQL Version: LI-V3.0.0.32136 Firebird 3.0 Release Candidate 1
Server version:
Firebird/Linux/AMD/Intel/x64 (access method), version "LI-V3.0.0.32136 Firebird 3.0 Release Candidate 1"
Firebird/Linux/AMD/Intel/x64 (remote server), version "LI-V3.0.0.32136 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13"
Firebird/Linux/AMD/Intel/x64 (remote interface), version "LI-V3.0.0.32136 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13"
on disk structure version 12.0