Hello Karol,
Thursday, June 16, 2016, 7:49:06 AM, you wrote:
>
> but this feature is considered for FB4 – then i need to know why this is
> important feature..
>
This whole topic is off-topic in firebird-support, which is about
current releases.
However, I'm sure others (including me) are
>>In this case, user1 does not know about user2. They live in two parallel
>>universes.
>>Dmitry
Then i do not know who can take risk that user1 in one "universe" (product) at
present day have e.g. two schemas and user2 have onother schema
and in the future user2 take decision to create another
Ok i then misunderstand some discussion obout increasing length of identifiers
to support then schemas
Now i understand that this is only minor preparation
regards,
karol Bieniaszewski
W dniu 2016-06-15 23:36:56 użytkownik Dmitry Yemanov
dim...@users.sourceforge.net [firebird-support]
Hello Karol,
Thursday, June 16, 2016, 7:49:06 AM, you wrote:
>
> but this feature is considered for FB4 – then i need to know why this is
> important feature..
>
This whole topic is off-topic in firebird-support, which is about
current releases.
However, I'm sure others (including me) are
15.06.2016 22:48, 'livius' wrote:
>
> we can write sql like
> select * from table_name but really this is
> select * from schema.table_name
> and if i write this in stored procedure – i suppose that “object_id”
> will be stored in blr(when schemas will be avaiable)
BLR will contain
15.06.2016 22:49, 'livius' wrote:
>
> but this feature is considered for FB4
No, it's not. At least not for v4.
Dmitry
15.06.2016 21:49, 'livius' liviusliv...@poczta.onet.pl [firebird-support] wrote:
> i need to know why this is important feature..
It is good from marketing POV. Biggest competitors have them, no matter what
for.
--
WBR, SD.
Hi,
but this feature is considered for FB4 – then i need to know why this is
important feature..
regards,
Karol Bieniaszewski
From: mailto:firebird-support@yahoogroups.com
Sent: Wednesday, June 15, 2016 4:16 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Schema
Hi,
thank you Dmitry – the last sentens show me some benefits
other sentenses show only complications for me.
we can write sql like
select * from table_name but really this is
select * from schema.table_name
and if i write this in stored procedure – i suppose that “object_id” will be
stored in
Hi,
do you mean that you share one connection between multiple threads?
regards,
Karol Bieniaszewski
From: mailto:firebird-support@yahoogroups.com
Sent: Wednesday, June 15, 2016 5:55 PM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] performance issue with firebird 3.0
The way I think of the Y-valve* is that the stem of the Y is the client -
whether the normal fbclient or the Java client or other language specific
clients. The connection request goes from the client to a provider.
Right now, the providers are Remote (which may be built into the Y-valve)
and
Hello Stefan,
> I expect that an accent insensitive compare treats accented characters
> as the "same" as their un-accented counterparts because the accent
> does not change the character itself but things like pronounciation or
> stress.
>
> So in Frech, à is similar to a, é is similar to è and
Thanks, Helen. Please see my replies inline.
I am sure it is not 3.0 specific, 2.5 is the same. and the main issue is
scalability, sequential transaction performance is actually pretty good,
comparable to ESE store on windows I was comparing firebird against. but when
running multiple
I expect that an accent insensitive compare treats accented characters
as the "same" as their un-accented counterparts because the accent
does not change the character itself but things like pronounciation or
stress.
So in Frech, à is similar to a, é is similar to è and you use an
accent
Firebird has no support for schemas, IIRC... or am I missing something?
Em dom, 12 de jun de 2016 às 18:18, 'livius' liviusliv...@poczta.onet.pl
[firebird-support] escreveu:
>
>
> Hi,
>
> what are + and – with working with schema?
> What benefits are between
>
13.06.2016 00:18, 'livius' wrote:
>
> what are + and – with working with schema?
> What benefits are between
> schema_name__table_name and real schema implementation?
> schema_name.table_name
Ability to have a default schema (per user, per connection). So that you
may have multiple completely
Hi,
anybody?
regars,
Karol Bieniaszewski
W dniu 2016-06-12 23:18:15 użytkownik livius
napisał:
Hi,
what are + and – with working with schema?
What benefits are between
schema_name__table_name and real schema implementation?
schema_name.table_name
I near to
15.06.2016 14:19, fabia...@itbizolutions.com.au [firebird-support] wrote:
> When I omit Engine12 from the provider's list at the server's config, to
> ensure the server
> always acts as a super server
This way you ensured that server cannot work with databases at all. I.e. it
cannot work
as
Dimitry
> No. Y-valve is fbclient.dll. It loads providers as configured. If you don't
> need to
> work with databases directly, you can omit Engine from list of providers.
> Firebird server (fbserver.exe) uses fbclient.dll the same way as any other
> application
mmm, now we are back to my
14.06.2016 22:46, fabia...@itbizolutions.com.au [firebird-support] wrote:
> It seems Engine12 is not the same "type of component" as the other Providers.
> In the
> documentation it is refered as a Y valve, if I understand it correctly
> Engine12 is the
> base of the Y, while the other providers
Wednesday, June 15, 2016, 5:58:39 PM, Karol B. wrote:
> test without details say nothing to me
> 1. Did you compare results with e.g. FB2.5 in on the same maschine with same
> configuration (FBConfig)
> 2. What is your page size and type of HDD?
> 3. Do you have BOST feature enabled on CPU and
21 matches
Mail list logo