[Firebird-devel] negative values performance info

2012-02-18 Thread Björn Reimer
Hello, As I didn't get an answer on the support list may be a developer can enlighten me. Executing a query with a little bit longer execution time I get negative numbers for some values. Execution is done via IBExpert. Firebird ist 2.5.1 CS on Linux 64 bit Client Lib is 2.5.1 Windows 32 b

Re: [Firebird-devel] negative values performance info - Email found in subject

2012-02-18 Thread Leyne, Sean
Björn, > Executing a query with a little bit longer execution time I get negative > numbers for some values. Execution is done via IBExpert. Firebird ist 2.5.1 > CS on Linux 64 bit Client Lib is 2.5.1 Windows 32 bit. > > Prepare time = 63ms > Execute time = 43h 53m 31s 63ms > Avg fetch time = 1

Re: [Firebird-devel] negative values performance info

2012-02-18 Thread Dmitry Yemanov
18.02.2012 16:54, Björn Reimer wrote: > > Current memory = -507.368.239 > Max memory = -466.997.327 > Memory buffers = 20.480 > Fetches from cache = -1.256.613.653 Historically, all performance counters were 32-bit. Later, they were enhanced to represent 64-bit values. Firebird 2.5 could report e

[Firebird-devel] isc_info_firebird_version without database handle

2012-02-18 Thread Jiri Cincura
Hi *, can I somehow ask for isc_info_firebird_version without database handle? I'd like to know it before processing op_attach. -- Jiri {x2} Cincura (x2develop.com founder) http://blog.cincura.net/ | http://www.ID3renamer.com -

Re: [Firebird-devel] isc_info_firebird_version without database handle

2012-02-18 Thread Dmitry Yemanov
18.02.2012 23:33, Jiri Cincura wrote: > > can I somehow ask for isc_info_firebird_version without database > handle? I'd like to know it before processing op_attach. You can use the service manager and ask it for isc_info_svc_server_version. Dmitry

Re: [Firebird-devel] CORE-3701 / JDBC-233 help needed

2012-02-18 Thread Dmitry Yemanov
15.02.2012 20:01, Mark Rotteveel wrote: > Does SQL_VARYING require the sqllen to be updated as well, or can that > be left as it was originally set by isc_dsql_describe_bind? I'd say it should correspond to the real data. You're not required to use isc_dsql_describe_bind(), after all. Dmitry