On 11/04/2013 02:12 AM, Vlad Khorsun wrote:
>> 03.11.2013 20:03, Vlad Khorsun wrote:
>>> "create database" runs instantly for me.
>>For me - not.
>>You can get Process Monitor's log here:
>> http://www.ibphoenix.com/ibpr_devel/Logfile.7z
>> It seems that most of the time were spend i
On 11/03/2013 07:09 PM, Mark Rotteveel wrote:
> On 3-11-2013 16:05, Mark Rotteveel wrote:
>> I am not sure if this behavior is desirable or correct. Based on the
>> documentation ("Enabled behavior depends another side requirements. If
>> both sides set to enabled, connection is encrypted") I'd say
On 11/03/2013 07:48 PM, Mark Rotteveel wrote:
> On 3-11-2013 16:05, Mark Rotteveel wrote:
>> I was still running against the FB 3 Alpha 1 and just upgraded to
>> 3.0.0.30708 by overwriting my Firebird 3 Alpha 1 install except
>> firebird.conf and security3.fdb.
>>
>> Now when using legacy_auth, ins
On 11/03/2013 05:51 PM, Dmitry Yemanov wrote:
> 03.11.2013 16:44, Mark Rotteveel wrote:
>
>> I have a test in Jaybird trunk which attempts to retrieve the execution
>> plan of an unprepared statement. In Firebird 2.5 the result is an empty
>> string as the plan. In Firebird 3 (alpha 1), this result
> 03.11.2013 20:03, Vlad Khorsun wrote:
>> "create database" runs instantly for me.
>
> For me - not.
> You can get Process Monitor's log here:
> http://www.ibphoenix.com/ibpr_devel/Logfile.7z
> It seems that most of the time were spend in looking for ICU library and
> synchronous
> wr
03.11.2013 20:03, Vlad Khorsun wrote:
> "create database" runs instantly for me.
For me - not.
You can get Process Monitor's log here:
http://www.ibphoenix.com/ibpr_devel/Logfile.7z
It seems that most of the time were spend in looking for ICU library and
synchronous
writing into data
> 03.11.2013 18:52, Vlad Khorsun wrote:
>>> Yes, isql shows the same behavior.
>> I can't reproduce it with just build fb3
>
> I can.
> Just unpacked today's snapshot, run 'fbserver -a',
There is no "fbserver" in fb3.
> isql and typed "create database
> 'test' user 'sysdba' pas
03.11.2013 19:07, Dimitry Sibiryakov wrote:
> 03.11.2013 18:52, Vlad Khorsun wrote:
>>> Yes, isql shows the same behavior.
>> I can't reproduce it with just build fb3
>
> I can.
> Just unpacked today's snapshot, run 'fbserver -a', isql and typed "create
> database
> 'test' user 'sysd
03.11.2013 18:52, Vlad Khorsun wrote:
>> Yes, isql shows the same behavior.
> I can't reproduce it with just build fb3
I can.
Just unpacked today's snapshot, run 'fbserver -a', isql and typed "create
database
'test' user 'sysdba' password 'masterkey';" statement. It produced a lot of
On 3-11-2013 18:52, Vlad Khorsun wrote:
>> On 3-11-2013 18:14, Vlad Khorsun wrote:
Final test took 26 minutes, it looks like the majority of the waiting
time is in the creation of a database (almost every individual test
creates a database), which takes 4-5 seconds, instead of < 1 se
> On 3-11-2013 18:14, Vlad Khorsun wrote:
>>> Final test took 26 minutes, it looks like the majority of the waiting
>>> time is in the creation of a database (almost every individual test
>>> creates a database), which takes 4-5 seconds, instead of < 1 second per
>>> database.
>>
>> Is it repr
On 3-11-2013 18:14, Vlad Khorsun wrote:
>> Final test took 26 minutes, it looks like the majority of the waiting
>> time is in the creation of a database (almost every individual test
>> creates a database), which takes 4-5 seconds, instead of < 1 second per
>> database.
>
> Is it reproducible
> Final test took 26 minutes, it looks like the majority of the waiting
> time is in the creation of a database (almost every individual test
> creates a database), which takes 4-5 seconds, instead of < 1 second per
> database.
Is it reproducible with isql ?
Regards,
Vlad
On 3-11-2013 17:28, Dimitry Sibiryakov wrote:
> 03.11.2013 16:59, Mark Rotteveel wrote:
>> Final test took 26 minutes, it looks like the majority of the waiting
>> time is in the creation of a database (almost every individual test
>> creates a database), which takes 4-5 seconds, instead of < 1 sec
03.11.2013 16:59, Mark Rotteveel wrote:
> Final test took 26 minutes, it looks like the majority of the waiting
> time is in the creation of a database (almost every individual test
> creates a database), which takes 4-5 seconds, instead of < 1 second per
> database.
Set Engine12 to be first pr
On 3-11-2013 16:26, Mark Rotteveel wrote:
> The Jaybird testsuite which takes 4.5 to 5 minutes against Firebird 3
> Alpha 1 is still running after 20 minutes on 3.0.0.30708 and it isn't
> even halfway through the tests.
>
> Any idea what might cause this?
Final test took 26 minutes, it looks like
On 3-11-2013 16:05, Mark Rotteveel wrote:
> I was still running against the FB 3 Alpha 1 and just upgraded to
> 3.0.0.30708 by overwriting my Firebird 3 Alpha 1 install except
> firebird.conf and security3.fdb.
>
> Now when using legacy_auth, instead of op_accept, all connection
> attempts receive
The Jaybird testsuite which takes 4.5 to 5 minutes against Firebird 3
Alpha 1 is still running after 20 minutes on 3.0.0.30708 and it isn't
even halfway through the tests.
Any idea what might cause this?
Mark
--
Mark Rotteveel
--
On 3-11-2013 16:05, Mark Rotteveel wrote:
> I am not sure if this behavior is desirable or correct. Based on the
> documentation ("Enabled behavior depends another side requirements. If
> both sides set to enabled, connection is encrypted") I'd say that
> setting it to Enabled should have been suff
I was still running against the FB 3 Alpha 1 and just upgraded to
3.0.0.30708 by overwriting my Firebird 3 Alpha 1 install except
firebird.conf and security3.fdb.
Now when using legacy_auth, instead of op_accept, all connection
attempts receive an op_reject.
I had to explicitly set WireCrypt =
03.11.2013 16:44, Mark Rotteveel wrote:
> I have a test in Jaybird trunk which attempts to retrieve the execution
> plan of an unprepared statement. In Firebird 2.5 the result is an empty
> string as the plan. In Firebird 3 (alpha 1), this results in an error
> with error code 335544711 (isc_unpre
On 31-10-2013 17:31, Alex Peshkoff wrote:
> On 10/31/13 20:20, liviusliv...@poczta.onet.pl wrote:
>> Hi,
>>
>> We store in thouse fields data usefull for application logic. Some dep info
>> or sime restriction. This was choose of project design at start and changing
>> it now will be risk but pos
I have a test in Jaybird trunk which attempts to retrieve the execution
plan of an unprepared statement. In Firebird 2.5 the result is an empty
string as the plan. In Firebird 3 (alpha 1), this results in an error
with error code 335544711 (isc_unprepared_stmt) and message "Attempt to
execute a
23 matches
Mail list logo
