Re: [Firebird-devel] UDF's in Firebird 3.0

2014-03-17 Thread Weverton Gomes
I'm running FB as a application, and it is installed in "Program Files\Firebird\Firebird_3_0" Weverton Gomes de Morais Tecnólogo em Redes de Comunicação Arquiteto de Software Desenvolvedor C# e Delphi Entusiasta Ruby/Rails "Todos juntos somos fortes" 2014-03-17 13:58 GMT-03:00 Leyne, Sean : >

Re: [Firebird-devel] UDF's in Firebird 3.0

2014-03-17 Thread Leyne, Sean
> The problemas was UAC. When I turned it off, all works normally. UAC should not impact services. Where you running FB as an application or service? What folder was your application installed in? What folder was FB installed in? Sean --

Re: [Firebird-devel] UDF's in Firebird 3.0

2014-03-17 Thread Weverton Gomes
The problemas was UAC. When I turned it off, all works normally. Weverton Gomes de Morais Tecnólogo em Redes de Comunicação Arquiteto de Software Desenvolvedor C# e Delphi Entusiasta Ruby/Rails "Todos juntos somos fortes" 2014-03-17 13:24 GMT-03:00 Dimitry Sibiryakov : > 17.03.2014 17:17, Wever

Re: [Firebird-devel] UDF's in Firebird 3.0

2014-03-17 Thread Dimitry Sibiryakov
17.03.2014 17:17, Weverton Gomes wrote: > May is this the cause of problem?? No. -- WBR, SD. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases

Re: [Firebird-devel] UDF's in Firebird 3.0

2014-03-17 Thread Weverton Gomes
Hi, I'm trying make this work on a machine who already has FB 2.0 and 2.5 instances running. May is this the cause of problem?? Weverton Gomes de Morais Tecnólogo em Redes de Comunicação Arquiteto de Software Desenvolvedor C# e Delphi Entusiasta Ruby/Rails "Todos juntos somos fortes" 2014-03-

Re: [Firebird-devel] Y-classes trickery

2014-03-17 Thread Dimitry Sibiryakov
17.03.2014 12:30, Alex Peshkoff wrote: > On 03/17/14 15:01, Dimitry Sibiryakov wrote: >> There is no such risk from the beginning because y-valve is single >> threaded as every >> call is protected with mutex. > > May be old API :) No, old API works the same way. >>Besides, storing r

Re: [Firebird-devel] Y-classes trickery

2014-03-17 Thread Alex Peshkoff
On 03/17/14 15:01, Dimitry Sibiryakov wrote: > 17.03.2014 8:47, Alex Peshkoff wrote: >> On 03/16/14 18:36, Dimitry Sibiryakov wrote: >>> Can someone explain me why Y-classes use strange tricks with >>> YEntry.next() instead of >>> direct calls to real interfaces returned by chosen provider?

Re: [Firebird-devel] Y-classes trickery

2014-03-17 Thread Dimitry Sibiryakov
17.03.2014 8:47, Alex Peshkoff wrote: > On 03/16/14 18:36, Dimitry Sibiryakov wrote: >> Can someone explain me why Y-classes use strange tricks with >> YEntry.next() instead of >> direct calls to real interfaces returned by chosen provider? > > Copying next pointer to local (on stack) referen

Re: [Firebird-devel] Delayed statement execution and transaction

2014-03-17 Thread Alex Peshkoff
On 03/16/14 19:41, Dimitry Sibiryakov wrote: > Hello, All. > > Currently when execution of a statement in why.cpp is delayed from > execute to fetch, > the transaction provided to execute call is saved and later used as is, > without any check. > Nevertheless, it is possible that a user b

Re: [Firebird-devel] Y-classes trickery

2014-03-17 Thread Alex Peshkoff
On 03/16/14 18:36, Dimitry Sibiryakov wrote: > Hello, All. > > Can someone explain me why Y-classes use strange tricks with > YEntry.next() instead of > direct calls to real interfaces returned by chosen provider? Copying next pointer to local (on stack) reference pointer helps to avoid