Re: [Firebird-devel] BLR contexts limit

24.03.2016 00:25, liviusliv...@poczta.onet.pl wrote: > > is this somehow implemented or stuck under not finished discussion? Implemented *but* stuck due to lack of comments ;-) > We are waiting for removing this limit : > Fingers crossed :) Are you prepared to lose the ability to migrate

Re: [Firebird-devel] BLR contexts limit

>>All, >> >>Can anyone think of any better idea? I have the former solution >>implemented, but maybe we could do something more clever? >>Dmitry Hi Dmitry, is this somehow implemented or stuck under not finished discussion? We are waiting for removing this limit : Fingers

[Firebird-devel] [FB-Tracker] Created: (CORE-5166) Wrong error message with UNIQUE BOOLEAN field

Wrong error message with UNIQUE BOOLEAN field - Key: CORE-5166 URL: http://tracker.firebirdsql.org/browse/CORE-5166 Project: Firebird Core Issue Type: Bug Components: Engine Affects

Re: [Firebird-devel] Atomics

23.03.2016 16:59, Jim Starkey wrote: > On 3/23/2016 5:04 AM, Vlad Khorsun wrote: >> All, >> >> in new codebase (v4) we going to use atomic operations more intensively than >> before. The question is: could we use standard features of C++11 or should >> choose some 3rd party library (such as

Re: [Firebird-devel] Atomics

On 3/23/2016 1:18 PM, Michal Kubecek wrote: > On Wed, Mar 23, 2016 at 10:59:20AM -0400, Jim Starkey wrote: >> Defining your own macro layer gives you cheap portability and a zero >> overhead implementation. > That's one side of it. The other is that for occasional contributors or > distribution

Re: [Firebird-devel] Atomics

On Wed, Mar 23, 2016 at 10:59:20AM -0400, Jim Starkey wrote: > > Defining your own macro layer gives you cheap portability and a zero > overhead implementation. That's one side of it. The other is that for occasional contributors or distribution support guys, it brings a lot of confusion. Like

Re: [Firebird-devel] Atomics

23.03.2016 14:05, Alex Peshkoff wrote: > Telling true I suppose both will add atomic support to the moment of FB4 > release. > But as long as they did not... > I suppose we keep our AtomicPointer and AtomicCounter, just implement > them internally using C++11. For existing 2 exceptions we keep

[Firebird-devel] [FB-Tracker] Created: (CORE-5165) HAVING COUNT(*) NOT IN ( ) prevent record from appearing in outer resultset when it should be there ( = resultset without nulls)

HAVING COUNT(*) NOT IN ( ) prevent record from appearing in outer resultset when it should be there ( = resultset without nulls) --- Key:

[Firebird-devel] Firebird.pas for the windows build

Firebird.pas is generated in the posix builds but it is not generated in the windows builds. Posix builds generate it via this target: $(API_PAS_FILE): $(IDL_FILE) $(PASCAL_SOURCES) $(TMP_FUNCS) $(CLOOP) $(IDL_FILE) pascal $@ Firebird --uses SysUtils \ --interfaceFile

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 18:14, Vlad Khorsun wrote: > > Original patch contains just "-I" switch :) For me both "inplace" and "merge" > are ok, let decide what to use. My point was to replace two switches (-inplace -restore) with one (-merge or whatever). Dmitry

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 17:01, Dmitry Yemanov wrote: > 23.03.2016 17:43, Vlad Khorsun wrote: >> >> apply new increment to the target database: >>nbackup -INPLACE -R target.fdb source-inc.nbk > > Wouldn't something like "nbackup -merge" be more user-friendly? Original patch contains just "-I"

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 17:43, Vlad Khorsun wrote: > > apply new increment to the target database: > nbackup -INPLACE -R target.fdb source-inc.nbk Wouldn't something like "nbackup -merge" be more user-friendly? Dmitry --

Re: [Firebird-devel] Atomics

On 3/23/2016 5:04 AM, Vlad Khorsun wrote: > All, > > in new codebase (v4) we going to use atomic operations more intensively than > before. The question is: could we use standard features of C++11 or should > choose some 3rd party library (such as libatomic_ops) for it ? > > The main

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 14:32, Dmitry Kuzmenko wrote: > Здравствуйте! > > Tuesday, March 22, 2016, 4:40:23 PM, you wrote: >>> 2) We added option into NBACKUP utility to create change set based on >>> baseline GUID rather than level. > > VK>Basic tests show it works :) If anyone have idea how to improve it

Re: [Firebird-devel] Extend ALTER EXTERNAL FUNCTION to adjust arguments

On 03/23/2016 03:34 PM, Dmitry Yemanov wrote: > 20.03.2016 14:27, Atri Sharma wrote: > >> Does this sound like an easy place to start? > It should be doable and probably you could take some ideas or even code > snippets from other places. > > First of all, syntax for ALTER EXTERNAL FUNCTION needs

Re: [Firebird-devel] Atomics

On 03/23/2016 01:55 PM, Vlad Khorsun wrote: > 23.03.2016 11:19, Alex Peshkoff wrote: >> On 03/23/2016 12:04 PM, Vlad Khorsun wrote: >>> All, >>> >>> in new codebase (v4) we going to use atomic operations more intensively than >>> before. The question is: could we use standard features of

Re: [Firebird-devel] Physical replication using NBACKUP

Здравствуйте! Tuesday, March 22, 2016, 4:40:23 PM, you wrote: >> 2) We added option into NBACKUP utility to create change set based on >> baseline GUID rather than level. VK>Basic tests show it works :) If anyone have idea how to improve it - you are welcome. VK> For example, we could

Re: [Firebird-devel] Extend ALTER EXTERNAL FUNCTION to adjust arguments

20.03.2016 14:27, Atri Sharma wrote: > Does this sound like an easy place to start? It should be doable and probably you could take some ideas or even code snippets from other places. First of all, syntax for ALTER EXTERNAL FUNCTION needs to be changed to match the one for DECLARE EXTERNAL

Re: [Firebird-devel] Atomics

> < Linux). > Is it a problem for us ?>> > > An interesting question, I do know of a few users who continue to use AIX and > HPUX and > who actively build on 2.5... Will we still have AIX and HPUX users by the > time we release > Firebird 4.0 - I don't know. <> Just an observation.

Re: [Firebird-devel] Atomics

23.03.2016 12:18, Paul Beach wrote: > < Linux). > Is it a problem for us ?>> > > An interesting question, I do know of a few users who continue to use AIX and > HPUX and > who actively build on 2.5... Will we still have AIX and HPUX users by the > time we release > Firebird 4.0 - I don't know.

Re: [Firebird-devel] Atomics

>> in new codebase (v4) we going to use atomic operations more intensively than >> before. The question is: could we use standard features of C++11 or should >> choose some 3rd party library (such as libatomic_ops) for it ? >> >> The main concern about C++11 atomics is - if all platforms

Re: [Firebird-devel] Atomics

23.03.2016 11:19, Alex Peshkoff wrote: > On 03/23/2016 12:04 PM, Vlad Khorsun wrote: >> All, >> >> in new codebase (v4) we going to use atomic operations more intensively than >> before. The question is: could we use standard features of C++11 or should >> choose some 3rd party library (such

Re: [Firebird-devel] Services and encoding

23.03.2016 11:01, Dmitry Yemanov wrote: > 1) No need to care about that tag -- simplify life for both end users > and connectivity layer developers. > > 2) Explicitly declare our UTF8 only future (in advance). I would prefer a brand-new API for that, not just a little hacking of old crap. --

Re: [Firebird-devel] Services and encoding

23.03.2016 12:56, Dimitry Sibiryakov wrote: > > what will be an advantage of the new DPB version except implicit isc_dpb_utf8 > tag? 1) No need to care about that tag -- simplify life for both end users and connectivity layer developers. 2) Explicitly declare our UTF8 only future (in advance).

Re: [Firebird-devel] Services and encoding

23.03.2016 10:53, Dmitry Yemanov wrote: > I didn't not suggest to remove/deprecate older DPB versions, so legacy > clients will be supported. Ok, but what will be an advantage of the new DPB version except implicit isc_dpb_utf8 tag? -- WBR, SD.

Re: [Firebird-devel] Services and encoding

23.03.2016 12:25, Dimitry Sibiryakov wrote: >> If we agree to move towards UTF8 in the long run, adding a new DPB/SPB >> version may be a good idea. Not necessarily in v4 though. > > Completely break backward-compatibility is a bad idea. I didn't not suggest to remove/deprecate older DPB

[Firebird-devel] [FB-Tracker] Created: (CORE-5164) Provide ability for fast receive number of current attachments, WITHOUT querying monitoring or call fb_lock_print and parsing its output

Provide ability for fast receive number of current attachments, WITHOUT querying monitoring or call fb_lock_print and parsing its output Key:

Re: [Firebird-devel] Atomics

> Having just checked - Clang (LLVM) 3.5 is installed via XCode on my Mac. So thats OK. Paul --

Re: [Firebird-devel] Services and encoding

23.03.2016 10:18, Dmitry Yemanov wrote: > Please let's avoid choosing bad names. It has nothing to do with > filenames. It should be something like isc_spb_utf8_data or > isc_spb_utf8_strings instead. And yes, we need to add a properly named > alias for isc_dpb_utf8_filename too. I agree that

Re: [Firebird-devel] Atomics

On 03/23/2016 12:04 PM, Vlad Khorsun wrote: > All, > > in new codebase (v4) we going to use atomic operations more intensively than > before. The question is: could we use standard features of C++11 or should > choose some 3rd party library (such as libatomic_ops) for it ? > > The main

Re: [Firebird-devel] Atomics

23.03.2016 10:13, Alex Peshkoff wrote: > The question was to people who aware - do compilers on MAC\HP\AIX\ARM > support C++11 atomics? If yes - absolutely no need in additional library. If these platforms don't support atomic ops, they have to emulate standard somehow. Or to be dropped from

Re: [Firebird-devel] Services and encoding

23.03.2016 12:10, Alex Peshkoff wrote: > > isc_spb_utf8_filename is enough, see no need to have new version. Please let's avoid choosing bad names. It has nothing to do with filenames. It should be something like isc_spb_utf8_data or isc_spb_utf8_strings instead. And yes, we need to add a

Re: [Firebird-devel] Restoring DB into shutdown state

>There is few shutdown mode's. Default one is "multi-user maintenance" > and it not prevents backup. If you need something non-default - specify > it explicitly. I used full shutdown mode. So the gbak not working is kind of expected. -- Mgr. Jiří Činčura Independent IT Specialist

Re: [Firebird-devel] Atomics

On 03/23/2016 12:06 PM, Dimitry Sibiryakov wrote: > 23.03.2016 10:04, Vlad Khorsun wrote: >> Opinions ? > I vote for C++11 standard. > That's not parliament to vote:) The question was to people who aware - do compilers on MAC\HP\AIX\ARM support C++11 atomics? If yes - absolutely no need

Re: [Firebird-devel] Services and encoding

23.03.2016 12:04, Mark Rotteveel wrote: > > In that case wouldn't it be better to bump the SPB version and declare > that from that version strings buffers are UTF-8 only? Shouldn't this idea be adapted for DPB as well? Dmitry

Re: [Firebird-devel] Services and encoding

On 03/23/2016 12:04 PM, Mark Rotteveel wrote: > On 22-3-2016 15:10, Alex Peshkoff wrote: >> On 03/22/2016 04:54 PM, Jim Starkey wrote: >>> On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote: Hello, All. Because there is nothing like isc_spb_lc_ctype, must be established

Re: [Firebird-devel] Services and encoding

23.03.2016 10:04, Mark Rotteveel wrote: > In that case wouldn't it be better to bump the SPB version and declare > that from that version strings buffers are UTF-8 only? It will add more problems with backward-compatibility with no gain. -- WBR, SD.

Re: [Firebird-devel] Atomics

+1 for a cross platform library On Wed, Mar 23, 2016 at 2:34 PM, Vlad Khorsun wrote: >All, > > in new codebase (v4) we going to use atomic operations more intensively > than > before. The question is: could we use standard features of C++11 or should > choose

Re: [Firebird-devel] Atomics

23.03.2016 10:04, Vlad Khorsun wrote: > Opinions ? I vote for C++11 standard. -- WBR, SD. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics

[Firebird-devel] Atomics

All, in new codebase (v4) we going to use atomic operations more intensively than before. The question is: could we use standard features of C++11 or should choose some 3rd party library (such as libatomic_ops) for it ? The main concern about C++11 atomics is - if all platforms where

Re: [Firebird-devel] Services and encoding

On 22-3-2016 15:10, Alex Peshkoff wrote: > On 03/22/2016 04:54 PM, Jim Starkey wrote: >> On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote: >>> Hello, All. >>> >>> Because there is nothing like isc_spb_lc_ctype, must be established a >>> rule for >>> determining of encoding of all

Re: [Firebird-devel] Restoring DB into shutdown state

23.03.2016 10:28, Jiří Činčura wrote: > I can't even backup database in shutdown mode. There is few shutdown mode's. Default one is "multi-user maintenance" and it not prevents backup. If you need something non-default - specify it explicitly. Regards, Vlad

Re: [Firebird-devel] Restoring DB into shutdown state

23.03.2016 10:22, Alex Peshkoff wrote: > On 03/23/2016 11:15 AM, Vlad Khorsun wrote: >> 23.03.2016 9:23, Jiří Činčura wrote: >>> Hi *, >>> >>> Is there a SPB combination to restore database and keep it in shutdown? >>> Hence manually requiring to online it? >> There is no direct way to do it

Re: [Firebird-devel] Restoring DB into shutdown state

> but you may put db i shutdown before backup and it will be restored in > the > same mode. I can't even backup database in shutdown mode. -- Mgr. Jiří Činčura Independent IT Specialist -- Transform Data into

Re: [Firebird-devel] Restoring DB into shutdown state

On 03/23/2016 11:15 AM, Vlad Khorsun wrote: > 23.03.2016 9:23, Jiří Činčura wrote: >> Hi *, >> >> Is there a SPB combination to restore database and keep it in shutdown? >> Hence manually requiring to online it? > There is no direct way to do it (probably it could be a useful new > feature),

Re: [Firebird-devel] Restoring DB into shutdown state

23.03.2016 9:23, Jiří Činčura wrote: > Hi *, > > Is there a SPB combination to restore database and keep it in shutdown? > Hence manually requiring to online it? There is no direct way to do it (probably it could be a useful new feature), but you may put db i shutdown before backup and it will

Re: [Firebird-devel] Restoring DB into shutdown state

On 03/23/2016 10:23 AM, Jiří Činčura wrote: > Hi *, > > Is there a SPB combination to restore database and keep it in shutdown? No > Hence manually requiring to online it? > > JC > -- Transform Data into Opportunity.

[Firebird-devel] Restoring DB into shutdown state

Hi *, Is there a SPB combination to restore database and keep it in shutdown? Hence manually requiring to online it? JC -- Mgr. Jiří Činčura Independent IT Specialist -- Transform Data into Opportunity. Accelerate