On Wed, Jan 4, 2012 at 2:23 AM, W O wrote:
> I agree.
>
> I just use FB 2.5
>
> Greetings.
>
> Walter.
I would go to accept only protocol from > 2.0
1.5.x is not supported anymore anyway
http://www.firebirdsql.org/en/roadmap/
>
>
>
>
> On Tue, Jan 3, 2012 at 5:39 PM, Mark Rotteveel wrote:
>>
>>
ARRAY of VARCHAR not utilizing the length indicator byte pair
-
Key: CORE-3716
URL: http://tracker.firebirdsql.org/browse/CORE-3716
Project: Firebird Core
Issue Type: Bug
I agree.
I just use FB 2.5
Greetings.
Walter.
On Tue, Jan 3, 2012 at 5:39 PM, Mark Rotteveel wrote:
> On 3-1-2012 17:04, Dmitry Yemanov wrote:
> > All,
> >
> > Would there be any objections if we remove the support for protocol
> > versions less than 10?
> >
> > It means that fbclient would
How do I debug if firebird server running with code changes that we made? I
am running fbserver.exe with "-a -p 3050 -database
"localhost:..\myDatabase.fdb"". Firebird tray icon is showing me that
nothing has been attached and nothing is happening outside of the windows
message loop. Also, when par
On Tue, Jan 3, 2012 at 4:56 PM, Mark Rotteveel wrote:
>>
>> The definitive sign of a computed field is RDB$COMPUTED_BLR in either
>> RDB$FIELDS or RDB$DOMAINS if the field is defined through a domain
> There is no RDB$DOMAINS ...
Too many databases... indeed, it's RDB$FIELDS not system.domai
Kjell,
>
> Or a more automated and built-in support to do such a
> replicate/backup/restore/reverse. For me it's question of time. Sure, I
> could learn how to setup a cluster and replication. But there are dozens
> of other things I also need to do yesterday, so having to learn this on
> top of
On 3-1-2012 22:38, Ann Harrison wrote:
> Mark,
>
>> I am currently going over the JDBC metadata returned by Jaybird, and I
>> was looking for a way to see if a column is COMPUTER BY / GENERATED
>> ALWAYS AS.
>>
>> I found that I should probably look at RDB$FIELDS.RDB$COMPUTED_BLR or
>> RDB$COMPUTED
On 3-1-2012 17:04, Dmitry Yemanov wrote:
> All,
>
> Would there be any objections if we remove the support for protocol
> versions less than 10?
>
> It means that fbclient would not connect to pre-v6 versions of InterBase
> and fbserver would not accept connections from pre-v6 versions of gds32.
>
On 3-1-2012 22:25, Mark Rotteveel wrote:
> What is the exact meaning of this field? Is it only 0 for computed
> columns, or also in other cases (eg views)? Both the Interbase 6 as
> Helen's book mention it is not used, but apparently it is used (or at
> least: being set).
Ok, I already answered pa
Mark,
> I am currently going over the JDBC metadata returned by Jaybird, and I
> was looking for a way to see if a column is COMPUTER BY / GENERATED
> ALWAYS AS.
>
> I found that I should probably look at RDB$FIELDS.RDB$COMPUTED_BLR or
> RDB$COMPUTED_SOURCE for this, but I noticed that
> RDB$RELAT
Den 2012-01-03 21:59 skrev Ann Harrison såhär:
> On Tue, Jan 3, 2012 at 3:06 PM, Dmitry Yemanov wrote:
>
>> In the past, I liked the idea to wrap the txn IDs, but now I'm more and
>> more keen to consider other solutions instead.
>>
> Completely agree - including having changed my mind. I agree
I am currently going over the JDBC metadata returned by Jaybird, and I
was looking for a way to see if a column is COMPUTER BY / GENERATED
ALWAYS AS.
I found that I should probably look at RDB$FIELDS.RDB$COMPUTED_BLR or
RDB$COMPUTED_SOURCE for this, but I noticed that
RDB$RELATION_FIELDS.RDB$U
On Tue, Jan 3, 2012 at 3:06 PM, Dmitry Yemanov wrote:
>
> In the past, I liked the idea to wrap the txn IDs, but now I'm more and
> more keen to consider other solutions instead.
>
Completely agree - including having changed my mind. I agree with
Dimitry S. that his replicate/backup/restore/rev
> -Original Message-
> From: Dmitry Yemanov [mailto:firebi...@yandex.ru]
> Sent: Martes, 03 de Enero de 2012 13:05
>
> Would there be any objections if we remove the support for protocol
> versions less than 10?
>
> It means that fbclient would not connect to pre-v6 versions
> of Inter
Den 2012-01-03 21:34 skrev Claudio Valderrama C. såhär:
> Hello, in the tracker, Paul Vinkenoog wrote:
>
> "BTW, please be aware that Firebird's WEEKDAY is not ISO-8601 compliant: it
> returns 0 for Sunday instead of 7."
>
> Hmm, what else is not ISO compliant in our routines? There are two ways to
Den 2012-01-03 21:11 skrev Dimitry Sibiryakov såhär:
> 03.01.2012 21:04, Kjell Rilbe wrote:
>> What's needed is, in principle, a task that reads through ALL record
>> versions, and for each one with transaction id< OIT, change it to OIT -
>> 1. When it has done that for the entire database, it ca
Hello, in the tracker, Paul Vinkenoog wrote:
"BTW, please be aware that Firebird's WEEKDAY is not ISO-8601 compliant: it
returns 0 for Sunday instead of 7."
Hmm, what else is not ISO compliant in our routines? There are two ways to
deal with this:
- create other options with "ISO" appended to the
04.01.2012 0:04, Kjell Rilbe wrote:
> To make this a bit less work intensive, would it be possible and a good
> idea to mark each database page with the lowest transaction id in use on
> that page? In that case, the task could skip all pages where this value
> is>= OIT - 1.
It could avoid page wr
03.01.2012 21:04, Kjell Rilbe wrote:
> What's needed is, in principle, a task that reads through ALL record
> versions, and for each one with transaction id< OIT, change it to OIT -
> 1. When it has done that for the entire database, it can move the max
> useable transaction id to OIT - 2.
It
Thomas,
> While the restore process is pretty much I/O bound,
While that is true for desktop PCs with HDDs (not SSDs) or server without a
cached RAID controllers, but it is certainly not true as a blanket statement.
There is plenty of room for more throughput.
> Another option might be to res
03.01.2012 23:49, Kjell Rilbe wrote:
> As far as I understand, with very limited knowledge about the ods, each
> version of each record contains the id of the transaction that created
> that record version. So, if transaction with id 5 created the record
> version it will say "5" in there, always,
Den 2012-01-01 21:31 skrev Kjell Rilbe såhär:
> 3. Stay at 32 bit id:s but somehow "compact" all id:s older than OIT(?)
> into OIT-1. Allow id:s to wrap around.
> Pros:
> - No extra disk space.
> - Probably rather simple code changes for id usage.
> Cons:
> - May be difficult to find an effective w
Actually, the telecom standard is 99.999% uptime which is referred to
as a "Five-Nines" system and we have had this for over a decade with
Firebird, running 24/7/365.
Our transaction count is quite high, if you consider the number of
databases being queried in parallel to perform the various tasks
03.01.2012 20:37, Leyne, Sean wrote:
> As for the FKs, I see the tool as being a some which needs to have the
> maximum performance.
If you are going to move whole database at once - yes. Fortunately, in most
cases it is
not necessary.
--
SY, SD.
---
>>> The problem is not downtime is how much downtime. Backup and restore is
>>> so much downtime.
>>
>> There are a couple of possible solutions which would reduce the downtime;
>> - a new backup/restore tool which would use multiple readers/writers to
>> minimize execution time,
>
> Here we're ta
Den 2012-01-03 20:14 skrev Woody såhär:
> Maybe I'm a little dense, (probably :), but doesn't FB already know what the
> oldest interesting transaction id is? Why couldn't transaction numbers be
> allowed to wrap back around up to that point? As long as transactions are
> committed at some point, t
Woody,
> Maybe I'm a little dense, (probably :), but doesn't FB already know what the
> oldest interesting transaction id is? Why couldn't transaction numbers be
> allowed to wrap back around up to that point? As long as transactions are
> committed at some point, the oldest transaction would move
> 03.01.2012 18:51, Leyne, Sean wrote:
> > - a "data port" utility which would allow for data to be ported from a live
> database to a new database while live is active but would need a finalization
> step where the live database is shutdown to apply the final data changes and
> add FK constraint
Ann,
> > - a new backup/restore tool which would use multiple readers/writers
> > to minimize execution time,
>
> Here we're talking about a logical backup that can be used to restart
> transaction numbers. Record numbers are based loosely on record storage
> location. Since a logical backup/re
From: "Ann Harrison"
> Dimitry,
>
>> And exactly this utility is called "replicator". If made right, it
>> doesn't need FK
>> deactivation and can do "finalization step" when new database is already
>> in use.
>> Aren't you tired inventing a wheel?..
>
> Different vehicles need different whe
Just throwing another thing: Isn't some form of journaling expected to
appear in Firebird, as I've heard in the past?
If yes, the journal could be used to consolidade old transaction in one
and implement the thing about adjusting the transaction number and
making it overlap as I said previously
03.01.2012 19:44, Ann Harrison wrote:
> I'm not sure that either replication or the
> mechanism Sean is proposing (similar to either the start of a shadow
> database or nbackup) can solve the overflowing transaction id problem.
Simply: let's say we have two synchronous database. One is primary
All,
In thinking about Yi Lu's imminent problem with the Firebird transaction number
size, I am wondering if as developers we have overlooked the "reasonableness"
of the situation (actually the lack thereof).
Reality: a simple backup / restore cycle is all that needs to be performed to
resolve
Dimitry,
>> - a "data port" utility which would allow for data to be ported from a live
>> database to a new database while live is active but would need a
>> finalization step where the live database is shutdown to apply the final
>> data changes and add FK constraints.
>
> And exactly this
Sean,
>
>> The problem is not downtime is how much downtime. Backup and restore is
>> so much downtime.
>
> There are a couple of possible solutions which would reduce the downtime;
> - a new backup/restore tool which would use multiple readers/writers to
> minimize execution time,
Here we're tal
03.01.2012 18:51, Leyne, Sean wrote:
> - a "data port" utility which would allow for data to be ported from a live
> database to a new database while live is active but would need a finalization
> step where the live database is shutdown to apply the final data changes and
> add FK constraints.
Jesus
> > Single server without downtime is a myth anyway.
> The problem is not downtime is how much downtime. Backup and restore is
> so much downtime.
If that is the case, how much downtime is acceptable?
There are a couple of possible solutions which would reduce the downtime;
- a new backu
On 01/03/12 20:04, Dmitry Yemanov wrote:
> All,
>
> Would there be any objections if we remove the support for protocol
> versions less than 10?
>
> It means that fbclient would not connect to pre-v6 versions of InterBase
> and fbserver would not accept connections from pre-v6 versions of gds32.
All,
Would there be any objections if we remove the support for protocol
versions less than 10?
It means that fbclient would not connect to pre-v6 versions of InterBase
and fbserver would not accept connections from pre-v6 versions of gds32.
All Firebird versions would still be supported, as w
Hi,
> >> The first week of a year is, by convention, the first week that contains
> >> the first Tuesday of the year.
>
> > For example, according to ISO 8601 I think the first week of a year is
> > the first week that has four or more days on the new year.
>
> > This seems to contradict what Pier
03.01.2012 18:20, Alex Peshkoff wrote:
>> How deep in call stack we going to propagate CALLER privileges (UDR call
>> some SQL statement which have UDR calls embedded and so on) ?
>
> May be unlimited?
No recursion is required at all. If UDP MY_PROC selects UDF MY_FUNC from
table T1 and MY_FUNC
03.01.2012 18:53, Vlad Khorsun wrote:
> If we speak about statements that issued by UDR - certainly.
I was speaking only about statements issued by UDR, as it was the
subject initiated by Dimitry Sibiryakov.
> But if we speak about
> UDR itself - what set of privileges should it have ? So far t
We have read that negative transaction IDs are used to indicate an invalid
transaction. Thus, we have decided to continue with the signed approach to
prevent logic problems.
--
View this message in context:
http://firebird.1100200.n4.nabble.com/Firebird-Transaction-ID-limit-solution-tp4230210p425
>> The first week of a year is, by convention, the first week that contains
>> the first Tuesday of the year.
> For example, according to ISO 8601 I think the first week of a year is
> the first week that has four or more days on the new year.
> This seems to contradict what Pierre wrote above.
On 01/03/12 18:53, Vlad Khorsun wrote:
>> 03.01.2012 18:06, Vlad Khorsun wrote:
>>> Who will be the CALLER if UDR function is used in SELECT statement issued by
>>> client ?
>> CALLER is UDR itself, so this question is meaningless for me, sorry.
> If we speak about statements that issued by UD
> 03.01.2012 18:06, Vlad Khorsun wrote:
>>
>> Who will be the CALLER if UDR function is used in SELECT statement issued by
>> client ?
>
> CALLER is UDR itself, so this question is meaningless for me, sorry.
If we speak about statements that issued by UDR - certainly. But if we
speak about
U
03.01.2012 18:06, Vlad Khorsun wrote:
>
> Who will be the CALLER if UDR function is used in SELECT statement issued by
> client ?
CALLER is UDR itself, so this question is meaningless for me, sorry.
Dmitry
--
Write once
Den 2012-01-03 15:11 skrev Pierre Yager (JIRA) såhär:
> EXTRACT(YEAR_FOR_WEEK from '2012-01-01')
>
>
> Key: CORE-3715
> URL: http://tracker.firebirdsql.org/browse/CORE-3715
> Project: Firebird Core
>
On 01/03/12 18:06, Vlad Khorsun wrote:
>> 03.01.2012 13:00, Alex Peshkoff wrote:
>>
>>> Not sure about current state of code (you can easily check yourself),
>>> but quite sure that UDRs should behave exactly like classical SPs, i.e.
>>> it should be possible to grant rights to them.
>> With the d
03.01.2012 18:09, Alex Peshkoff wrote:
> Definitely. I was talking about ability to grant privileges to the whole
> external procedure as an object :-)
Me too :-) I was describing how it's going to work. Caller is an UDR, so
caller privileges are privileges granted to that UDR.
Dmitry
---
EXTRACT(YEAR_FOR_WEEK from '2012-01-01')
Key: CORE-3715
URL: http://tracker.firebirdsql.org/browse/CORE-3715
Project: Firebird Core
Issue Type: Improvement
Components: Engine
Affects Ver
On 01/03/12 17:58, Dmitry Yemanov wrote:
> 03.01.2012 17:40, Alex Peshkoff wrote:
>
>> In EXECUTE STATEMENT certainly yes. But I do not understand why should
>> external procedure behave like EXECUTE STATEMENT, not like any other
>> stored procedure.
> We seem to have some misunderstanding :-)
>
> 03.01.2012 13:00, Alex Peshkoff wrote:
>
>> Not sure about current state of code (you can easily check yourself),
>> but quite sure that UDRs should behave exactly like classical SPs, i.e.
>> it should be possible to grant rights to them.
>
> With the difference that these grants cannot be chec
03.01.2012 17:40, Alex Peshkoff wrote:
> In EXECUTE STATEMENT certainly yes. But I do not understand why should
> external procedure behave like EXECUTE STATEMENT, not like any other
> stored procedure.
We seem to have some misunderstanding :-)
Both UDRs and EXECUTE STATEMENTs deal with dynamic
On 01/03/12 17:35, Dmitry Yemanov wrote:
> 03.01.2012 17:25, Alex Peshkoff wrote:
>
>>> I believe that the internal UDR queries should work exactly like
>>> EXECUTE STATEMENT WITH CALLER PRIVILEGES. Dunno however whether its
>>> already the case or still in the pipeline.
>> Why only caller privile
03.01.2012 17:25, Alex Peshkoff wrote:
>> I believe that the internal UDR queries should work exactly like
>> EXECUTE STATEMENT WITH CALLER PRIVILEGES. Dunno however whether its
>> already the case or still in the pipeline.
>
> Why only caller privileges? If we have external procedure, what's wron
On 01/03/12 16:25, Adriano dos Santos Fernandes wrote:
> Firebird needs what is called "definers right" in Oracle (as opposed to
> our "invokers rights").
If it will not be used by default - why not?
--
Write once. Por
On 01/03/12 16:11, Dmitry Yemanov wrote:
> 03.01.2012 13:00, Alex Peshkoff wrote:
>
>> Not sure about current state of code (you can easily check yourself),
>> but quite sure that UDRs should behave exactly like classical SPs, i.e.
>> it should be possible to grant rights to them.
> With the diffe
On 01/01/12 04:07, W O wrote:
> You are right Alexander but with computers each month more and more fast,
> that's really a problem today?
Practice says that it is still a problem, at least at user's brain level :)
We increased record number size in FB2, and I've used to hear many times
- well, w
On 12/22/11 07:12, Doug Chamberlin wrote:
> Why limit it to so little? Make the limit 1KB or 2KB to encourage pass
> phrases instead of passwords.
>
> Full sentences that are meaningful to the person are WAY better
> protection than complex passwords.
Currently (fb3) firebird does not artificiall
03.01.2012 13:35, Adriano dos Santos Fernandes wrote:
> They could not, if newbies are not DBA(ing).
Heh! And they called me "sarcastic" when I said that DBA requires a brain...
--
SY, SD.
--
Write once. Port to m
03.01.2012 13:29, Dmitry Yemanov wrote:
> Could you elaborate?
As I said in my answer to Adriano: "definer rights" clause gives procedure
_all_ rights
of the creator. In most cases it is redundant and in some cases - insecure. I
would prefer
to be able to grant only really necessary rights.
On 03/01/2012 10:30, Dimitry Sibiryakov wrote:
> 03.01.2012 13:25, Adriano dos Santos Fernandes wrote:
>> Firebird needs what is called "definers right" in Oracle (as opposed to
>> our "invokers rights").
> But not for UDR. External libraries can be substituted/hacked. Giving
> them all
> defi
03.01.2012 13:25, Adriano dos Santos Fernandes wrote:
> Firebird needs what is called "definers right" in Oracle (as opposed to
> our "invokers rights").
But not for UDR. External libraries can be substituted/hacked. Giving them
all
definer's rights is insecure.
--
SY, SD.
-
03.01.2012 16:16, Dimitry Sibiryakov wrote:
> 03.01.2012 13:11, Dmitry Yemanov wrote:
>> I believe that the internal UDR queries should work exactly like
>> EXECUTE STATEMENT WITH CALLER PRIVILEGES.
>
> I would prefer fine-grained rights instead of bunch...
Could you elaborate?
Dmitry
Firebird needs what is called "definers right" in Oracle (as opposed to
our "invokers rights").
External routines should work like internals one. What matters is the
routine declaration, definers/invokers rights.
Adriano
---
03.01.2012 13:11, Dmitry Yemanov wrote:
> I believe that the internal UDR queries should work exactly like
> EXECUTE STATEMENT WITH CALLER PRIVILEGES.
I would prefer fine-grained rights instead of bunch...
--
SY, SD.
03.01.2012 13:00, Alex Peshkoff wrote:
> Not sure about current state of code (you can easily check yourself),
> but quite sure that UDRs should behave exactly like classical SPs, i.e.
> it should be possible to grant rights to them.
With the difference that these grants cannot be checked at the
On 12/31/11 17:53, Dimitry Sibiryakov wrote:
>Hello, All.
>
>If (as in examples) user defined routines perform some SQL queries against
> the
> database, must current user have rights on referenced objects or these rights
> can be
> granted to the routines only as it is done for classi
69 matches
Mail list logo
