Changed values for some parameters from DPB are not shown in RDB$CONFIG
Changed values of per-connection parameters (which are set in DPB) are not reflected in result of query to RDB$CONFIG - at least if INET/XNET protocols are used. This can be seen in following Python script:
import os
import argparse as ap
from firebird.driver import *
parser = ap.ArgumentParser()
parser.add_argument("fb_clnt", help="Path to FB client library")
parser.add_argument("protocol", nargs='?', default='inet', type = str.lower, choices = ('xnet', 'wnet', 'inet', 'inet4', 'local'), help="Protocol to be used for connection.")
args = parser.parse_args()
assert os.path.isfile(args.fb_clnt), "FB client library not found: '%s'" % args.fb_clnt
for v in ('ISC_USER','ISC_PASSWORD'):
try:
del os.environ[ v ]
except KeyError as e:
pass
# Register server
srv_cfg = """
[test_srv]
user = SYSDBA
password = masterkey
"""
driver_config.fb_client_library.value = args.fb_clnt
driver_config.register_server('test_srv', srv_cfg)
# Register database
db_cfg = f"""
[test_db]
database = employee
server = test_srv
config =
WireCryptPlugin = Arc4
WireCompression = True
"""
db_cfg_obj = driver_config.register_database( name = 'test_db', config = db_cfg)
if args.protocol.lower() == 'inet':
db_cfg_obj.protocol.value = NetProtocol.INET
elif args.protocol.lower() == 'inet4':
db_cfg_obj.protocol.value = NetProtocol.INET4
elif args.protocol.lower() == 'xnet':
db_cfg_obj.protocol.value = NetProtocol.XNET
elif args.protocol.lower() == 'wnet':
db_cfg_obj.protocol.value = NetProtocol.WNET
db_cfg_obj.auth_plugin_list.value = 'Srp'
db_cfg_obj.session_time_zone.value = 'Indian/Cocos'
db_cfg_obj.parallel_workers.value = 2
db_cfg_obj.charset.value = 'win1257'
db_cfg_obj.sql_dialect.value = 1
db_cfg_obj.dummy_packet_interval.value = 123
db_cfg_obj.decfloat_round.value = DecfloatRound.DOWN
with connect('test_db', no_gc = True) as con:
print('Established connection to', con.info.version)
cur = con.cursor()
test_sql = """
select
current_timestamp
, m.mon$database_name
, a.mon$remote_protocol
, a.mon$auth_method
, a.mon$session_timezone
, a.mon$parallel_workers
, c.rdb$character_set_name
, a.mon$wire_compressed
, a.mon$wire_crypt_plugin
, iif(1/3 = cast(1/3 as int), 3, 1) as client_dialect
, round(cast(12.341 as decfloat),2) as decfloat_round
from mon$database m
join mon$attachments a on a.mon$attachment_id = current_connection
join rdb$character_sets c on a.mon$character_set_id = c.rdb$character_set_id
"""
cur.execute(test_sql)
ccol=cur.description
for r in cur:
for i in range(0,len(ccol)):
print( ccol[i][0].ljust(32),':', r[i] )
print('-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-')
test_sql = """
select
g.rdb$config_name
, g.rdb$config_value
from rdb$config g
where g.rdb$config_name in (
'AuthClient'
, 'AuthServer'
, 'ParallelWorkers'
, 'WireCompression'
, 'WireCryptPlugin'
)
order by g.rdb$config_name
"""
cur.execute(test_sql)
ccol=cur.description
for r in cur:
for i in range(0,len(ccol)):
print( ccol[i][0].ljust(32),':', r[i] )
print('')
print('Bye.')
Let name of this script is: pass-dpb-params-test.py
To run this script, one need to specify mandatory 1st argument = full path to client library.
Second argument is optional and can be one of: inet | inet4 | xnet | wnet | local
So, i've ran this script two times:
python C:\FBTESTING\qa\misc\pass-dpb-params-test.py C:\FB\60SS\fbclient.dll inet 1>pass-dpb-params-test.6x-ss.inet.logpython C:\FBTESTING\qa\misc\pass-dpb-params-test.py C:\FB\60SS\fbclient.dll local 1>pass-dpb-params-test.6x-ss.local.log
Both logs are in attached .zip: pass-dpb-params-test_-_inet_xnet_and_local-protocols.zip
For INET one may see that:
- all parameters from DPB definitely were applied if we check content of mon$attachments or check arithmetic results (for sql_dialect and decfloat_round):
CURRENT_TIMESTAMP : 2025-08-14 03:26:48.778000+06:30
MON$DATABASE_NAME : C:\FB\60SS\examples\empbuild\employee.fdb
MON$REMOTE_PROTOCOL : TCPv6
MON$AUTH_METHOD : Srp
MON$SESSION_TIMEZONE : Indian/Cocos
MON$PARALLEL_WORKERS : 2
RDB$CHARACTER_SET_NAME : WIN1257
MON$WIRE_COMPRESSED : True
MON$WIRE_CRYPT_PLUGIN : Arc4
CLIENT_DIALECT : 1
DECFLOAT_ROUND : 12.34
(time 03:26:48 was shifted from my current timezone (MSK) for 5h 30 min - this is expected).
- NONE of parameters from the list
[AuthClient; ParallelWorkers; WireCompression; WireCryptPlugin]can be seen as changed in RDB$CONFIG:
RDB$CONFIG_NAME : AuthClient
RDB$CONFIG_VALUE : Srp256, Srp, Win_Sspi, Legacy_Auth -- WRONG. Expected: "Srp" only.
RDB$CONFIG_NAME : AuthServer
RDB$CONFIG_VALUE : Srp, Win_Sspi, Legacy_Auth
RDB$CONFIG_NAME : ParallelWorkers
RDB$CONFIG_VALUE : 1 -- WRONG. Expected: 2
RDB$CONFIG_NAME : WireCompression
RDB$CONFIG_VALUE : false -- WRONG. Expected: true
RDB$CONFIG_NAME : WireCryptPlugin
RDB$CONFIG_VALUE : ChaCha64, ChaCha, Arc4 -- WRONG. Expected: "Arc4" only.
For LOCAL protocol: 0) we can not compare values of MON$REMOTE_PROTOCOL, MON$WIRE_COMPRESSED, MON$WIRE_CRYPT_PLUGIN because they are NULL;
- MON$SESSION_TIMEZONE, MON$PARALLEL_WORKERS, RDB$CHARACTER_SET_NAME -- equal to appropriate values from DPB. Same for sql_dialect and decfloat_round.
- RDB$CONFIG: 2.1) contains correct values for WireCompression and WireCryptPlugin 2.2) still contains not-changed (default) values for rest params: AuthClient and ParallelWorkers.
This is comparison of two logs and mismatches:
That is entirely expected. Those setting are specific to the client, and do not update the configuration of the server. That is WireCompression only decides if the client will ask to set up wire compression, and AuthClient, the setting the client will use when authenticating, and similar for WireCryptPlugin. These settings when applied to the client do not configure the server, and therefor are not reported in RDB$CONFIG.
The result of the connection handshake is also not reported in RDB$CONFIG.
The reported values in RDB$CONFIG are the settings that the server applies, for example, the settings of AuthClient and WireCompression reported are the settings that the server will use when it makes an external connection to another database. And the WireCryptPlugin reported is what it will use when accepting connections and creating external connections.
Some of the client settings, those actually sent to the server in the DPB, which the previously mentioned settings are not (the isc_dpb_config they are configured in is not forwarded to the server!), because they influence behaviour of the current connection.
That they are reported for "local", is because that is actually embedded, and there the client is the server.
Missed the parallel workers case. That does seem like something that should be reported in RDB$CONFIG, I think.
As an aside, consider including RDB$CONFIG_SOURCE in your query, so you can also see where the value was sourced.
consider including RDB$CONFIG_SOURCE in your query, so you can also see where the value was sourced.
I've done this + added check for 'DefaultTimeZone' and 'Providers' parameters:
. . .
# Register database
db_cfg = f"""
[test_db]
database = employee
server = test_srv
config =
WireCryptPlugin = Arc4
WireCompression = True
Providers = Engine14,Loopback,Remote
DefaultTimeZone = Pacific/Tahiti
"""
. . .
Modified script is in attach: pass-dpb-params-test.2.py.zip
If run this script with requirement to use local protocol (python pass-dpb-params-test.py C:\FB\60SS\fbclient.dll local) then output will be:
Established connection to 6.0.0.1164
CURRENT_TIMESTAMP : 2025-08-14 14:28:49.575000+06:30
MON$DATABASE_NAME : C:\FB\60SS\examples\empbuild\employee.fdb
MON$REMOTE_PROTOCOL : None
MON$AUTH_METHOD : User name in DPB
MON$SESSION_TIMEZONE : Indian/Cocos
MON$PARALLEL_WORKERS : 2
RDB$CHARACTER_SET_NAME : WIN1257
MON$WIRE_COMPRESSED : None
MON$WIRE_CRYPT_PLUGIN : None
CLIENT_DIALECT : 1
DECFLOAT_ROUND : 12.34
-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-
RDB$CONFIG_NAME : AuthClient
RDB$CONFIG_VALUE : Srp256, Srp, Win_Sspi, Legacy_Auth
RDB$CONFIG_SOURCE : firebird.conf
RDB$CONFIG_NAME : AuthServer
RDB$CONFIG_VALUE : Srp, Win_Sspi, Legacy_Auth
RDB$CONFIG_SOURCE : firebird.conf
RDB$CONFIG_NAME : DefaultTimeZone
RDB$CONFIG_VALUE : None
RDB$CONFIG_SOURCE : None
RDB$CONFIG_NAME : ParallelWorkers
RDB$CONFIG_VALUE : 1
RDB$CONFIG_SOURCE : None
RDB$CONFIG_NAME : Providers
RDB$CONFIG_VALUE : Engine14,Loopback,Remote // yes, it differs from default
RDB$CONFIG_SOURCE : <DPB>
RDB$CONFIG_NAME : WireCompression
RDB$CONFIG_VALUE : true
RDB$CONFIG_SOURCE : <DPB>
RDB$CONFIG_NAME : WireCryptPlugin
RDB$CONFIG_VALUE : Arc4
RDB$CONFIG_SOURCE : <DPB>
RDB$CONFIG_SOURCE values for DefaultTimeZone (which was set to 'Pacific/Tahiti') and ParallelWorkers remain NULL - i.e. like they were not specified in DPB.
And it seems that at least DefaultTimeZone really absents in the DPB because if we comment out line N 52 (see .py-script in attached .zip):
# db_cfg_obj.session_time_zone.value = 'Indian/Cocos'
-- then output will show my OS timezone (eur/msk) instead of 'Pacific/Tahiti'.
PS.
And one more Q.
Changed value of 'Providers' will not be seen in rdb$config if we use non-local protocol.
Should 'Providers' be considered as client-side parameter (like Wire* parameters are) ?
I always thought that Providers = [list] declares set of connection methods that are allowed from the server's point of view
The local thing is a red herring, because that is embedded, and there the client is the server, and the isc_dpb_config value then has influence on the server configuration, but not for any remote connections. There, any value set in the isc_dpb_config is a client only configuration, and not communicated with the server, unless it is a setting that results in fbclient automatically setting a DPB item.
The DefaultTimeZone setting != isc_dpb_session_time_zone, so setting it client side does not configure the value of DefaultTimeZone on the server (except for embedded). However, from the client perspective, it should configure isc_dpb_session_time_zone (according to what's documented in firebird.conf) if none was set explicitly. If that doesn't happen, then that is also a bug, but should be reported separately.
And yes, Providers is a local setting, and only decides the providers the client tries to create a connection. The configuration on the client cannot and does not influence the providers the server (other than embedded) will attempt to use (if it could, that would be pretty much a security issue).