Dmitry Yemanov [2011-11-30 08:44] :
> Please test it and suggest any corrections.
For Linux 2.5.1 tar.gz is a better default choice than rpm
--
All the data continuously generated in your IT infrastructure
contains a de
30.11.2011 11:37, Dmitry Yemanov wrote:
> So the reason is elsewhere.
Found it. SF has an ability to set the default download for the every
major platform (Win/Lin/Mac/etc). This option was left empty for the
server binaries but set for the .NET provider packages.
I have it fixed now for Windo
30.11.2011 11:30, Dmitry Yemanov wrote:
> AFAIK, this is how SF advertises the latest package published by the
> project.
Well, this guess looks wrong. The .NET provider has been updated in June
while we had a v2.5.1 release in October. So the reason is elsewhere.
Dmitry
-
On 11/30/11 11:16, Dmitry Kuzmenko wrote:
> Hello, All!
>
> I'm sorry writing this question here, bit I have not
> access to firebird-admins.
>
> Is it normal that SF alway suggesting to download
> .Net driver?
>
> For example, when I open
> https://sourceforge.net/projects/firebird/
>
> I see hug
30.11.2011 11:16, Dmitry Kuzmenko wrote:
>
> Is it normal that SF alway suggesting to download
> .Net driver?
>
> For example, when I open
> https://sourceforge.net/projects/firebird/
>
> I see huge green button recommending me to
> download .Net driver.
> Under this button is link
> Browse All Fil
Hello, All!
I'm sorry writing this question here, bit I have not
access to firebird-admins.
Is it normal that SF alway suggesting to download
.Net driver?
For example, when I open
https://sourceforge.net/projects/firebird/
I see huge green button recommending me to
download .Net driver.
Under t
On 11/30/11 02:42, Frank Ingermann wrote:
> DROP SOURCE OF [||*]
> or
> CHANGE OWNER OF [|*] TO
This approach looks much better than use of system package.
--
All the data continuously generated in your IT infrastructu
Hi Sean / *,
Am 29.11.2011 22:47, schrieb Leyne, Sean:
> Again, though how would that be done in SQL?
right - the original question was: can direct modification
of system tables be completely disabled, and (if yes):
what alternatives would we need...to still be able to do
what we do nowadays _wit
On 29-11-2011 05:56, Dmitry Yemanov wrote:
> 28.11.2011 23:08, Adriano dos Santos Fernandes wrote:
>
>> No. It happens with large varchar column. So it turns back to my
>> question: can we describe a column with a length we know will fit and
>> will have no side effects other than just being descr
On 29-11-2011 19:47, Leyne, Sean wrote:
> Adriano,
>
>> I thing something like:
>>
>> firebird.set_comment(, , )
>
> Seems fine to me. But how would that be done in SQL statement, without
> direct manipulation of the system tables?
>
>
BTW, "FIREBIRD" seems a not good name for that. Better re
Adriano,
> I thing something like:
>
> firebird.set_comment(, , )
Seems fine to me. But how would that be done in SQL statement, without direct
manipulation of the system tables?
> firebird.set_source(, , )
This would allow for a user to set the source to be any value (= "Hello
World"). {
On 29-11-2011 18:28, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
>> Sent: Martes, 29 de Noviembre de 2011 6:41
>>>
>> I believe it's better to have a system package with functions
>> able to do
>> that, instead of
How about a command that actually shows the comments on an object
without having to read the system tables?
Security grants for creating and viewing the comments?
Right now you can use various tricks to grant and revoke rights on
system tables, giving various levels of security, but there is no
n
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Martes, 29 de Noviembre de 2011 6:41
> >
> I believe it's better to have a system package with functions
> able to do
> that, instead of continue allowing these changes directly.
Yes, no more
On 11/29/11 13:37, Adriano dos Santos Fernandes wrote:
> On 29/11/2011 05:49, Alex Peshkoff wrote:
>
>> May be we can think about builting function like index_expr. That's just
>> raw idea, but may be something like
>> INDEX_EXPR(ALIAS.indexName)
>> is better than
>>
> This is up to the user to c
Hello.
I may be wrong, but I'm unable to find a way how a trace plugin can call
engine to get
more information that is sent via parameters.
Particularly I'm interested in getting BLOB/array content from
trace_dsql_execute()
handler.
Is it possible to expand TraceConnection class to
I think very strange to still have to build
DPB by hand... Can you expose something that may give access to the
ClumpletWriter to ease that ?
>>> Probably it's worth thinking about it, but IMHO building parameters
>>> block is not critical from API point of view.
>> But it does add t
On 29/11/2011 06:01, Dmitry Yemanov wrote:
> 28.11.2011 23:51, Helen Borrie wrote:
>
>> Here's another one: the COMMENT syntax for loading varchar text into
>> RDB$DESCRIPTION.
> Frank has shown a somewhat similar one: it's a more or less common
> practice to empty/nullify the RDB$***_SOURCE colu
On 29/11/2011 05:49, Alex Peshkoff wrote:
> On 11/29/11 04:42, Claudio Valderrama C. wrote:
>>> -Original Message-
>>> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
>>> Sent: Lunes, 28 de Noviembre de 2011 16:08
>>> No. It happens with large varchar column. So it turns b
On Tue, 29 Nov 2011 10:26:10 +0100, Dimitry Sibiryakov
wrote:
> 29.11.2011 10:20, Mark Rotteveel wrote:
>> Wouldn't that give false positives? Or does the engine also compare the
>> actual (full) value after identifying a row in the index?
>
>Yes, real values are always evaluated for rows sel
29.11.2011 10:20, Mark Rotteveel wrote:
> Wouldn't that give false positives? Or does the engine also compare the
> actual (full) value after identifying a row in the index?
Yes, real values are always evaluated for rows selected by index.
--
SY, SD.
--
>> -Original Message-
>> From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
>> Sent: Martes, 29 de Noviembre de 2011 5:36
>>
>> While i agree with you about SUBSTRING, i think the much
>> better solution
>> will be to allow to index COMPUTED BY columns. It allows to
>> not comp
- Original Message -
From: "Claudio Valderrama C."
To: "'For discussion among Firebird Developers'"
Sent: Tuesday, November 29, 2011 11:00 AM
Subject: Re: [Firebird-devel] Created: (CORE-3672) computed indexbysubstring
function for long columns
>> -Original Message-
>> From:
> 29.11.2011 12:35, Vlad Khorsun wrote:
>
>> While i agree with you about SUBSTRING, i think the much better solution
>> will be to allow to index COMPUTED BY columns. It allows to not compare
>> potentially complex expressions at optimize time and to not write exactly
>> same expressions in every
29.11.2011 10:16, Mark Rotteveel wrote:
> Why shouldn't it be readable? It is very useful to retrieve and show
> metadata and regenerate DDL with a admin tool like flamerobin, or Eclipse
> Data Tools Platform.
They should be readable for owner and sysdba only.
--
SY, SD.
-
On Tue, 29 Nov 2011 10:07:29 +0100, Dimitry Sibiryakov
wrote:
>Perhaps, better approach would be silently cut long index keys to
>implementation limit.
> This way we don't loose anything, just increase number of "real
> comparsions" with negative
> result during selects.
Wouldn't that gi
On Tue, 29 Nov 2011 10:04:58 +0100, Dimitry Sibiryakov
wrote:
> 29.11.2011 9:01, Dmitry Yemanov wrote:
>> Frank has shown a somewhat similar one: it's a more or less common
>> practice to empty/nullify the RDB$***_SOURCE columns.
>>
>> So perhaps, unless some good alternative can be offered, we co
29.11.2011 9:48, Dmitry Yemanov wrote:
> 29.11.2011 12:35, Vlad Khorsun wrote:
>
>> > While i agree with you about SUBSTRING, i think the much better solution
>> > will be to allow to index COMPUTED BY columns. It allows to not compare
>> > potentially complex expressions at optimize time and to
29.11.2011 9:01, Dmitry Yemanov wrote:
> Frank has shown a somewhat similar one: it's a more or less common
> practice to empty/nullify the RDB$***_SOURCE columns.
>
> So perhaps, unless some good alternative can be offered, we could still
> allow modifications of particular columns that are known
> -Original Message-
> From: Vlad Khorsun [mailto:hv...@users.sourceforge.net]
> Sent: Martes, 29 de Noviembre de 2011 5:36
>
> While i agree with you about SUBSTRING, i think the much
> better solution
> will be to allow to index COMPUTED BY columns. It allows to
> not compare
> po
29.11.2011 12:35, Vlad Khorsun wrote:
> While i agree with you about SUBSTRING, i think the much better solution
> will be to allow to index COMPUTED BY columns. It allows to not compare
> potentially complex expressions at optimize time and to not write exactly
> same expressions in every query w
> 28.11.2011 23:08, Adriano dos Santos Fernandes wrote:
>
>> No. It happens with large varchar column. So it turns back to my
>> question: can we describe a column with a length we know will fit and
>> will have no side effects other than just being described different?
>
> I believe we can and w
At 08:40 PM 29/11/2011, Alex Peshkoff wrote:
>I'd better think about an ability to use BLOB in COMMENT. On the other
>hand, is it really required to have comments >32765/3 characters? This
>looks sooner not like a comment, but an average size presentation :)
Well it could be. Are we going to di
On 11/29/11 12:23, Mark Rotteveel wrote:
> On Tue, 29 Nov 2011 11:19:27 +0400, Alex Peshkoff
> wrote:
>>> I think very strange to still have to build
>>> DPB by hand... Can you expose something that may give access to the
>>> ClumpletWriter to ease that ?
>> Probably it's worth thinking about it,
On Tue, 29 Nov 2011 11:19:27 +0400, Alex Peshkoff
wrote:
>> I think very strange to still have to build
>> DPB by hand... Can you expose something that may give access to the
>> ClumpletWriter to ease that ?
>
> Probably it's worth thinking about it, but IMHO building parameters
> block is not cr
28.11.2011 23:51, Helen Borrie wrote:
> Here's another one: the COMMENT syntax for loading varchar text into
> RDB$DESCRIPTION.
Frank has shown a somewhat similar one: it's a more or less common
practice to empty/nullify the RDB$***_SOURCE columns.
So perhaps, unless some good alternative can
36 matches
Mail list logo
