Frank wrote:
Using the API is one thing, but imho it should be possible to do all of
that
from within a SQL script - like
DROP SOURCE OF [procedure name|trigger name|*] or CHANGE
OWNER OF [db object|*] TO new_owner
I like this.
What about view name?
Magnus
On 11/30/11 02:42, Frank Ingermann wrote:
DROP SOURCE OF [procedure name|trigger name|*]
or
CHANGE OWNER OF [db object|*] TOnew_owner
This approach looks much better than use of system package.
Or more object type bound, e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE
30.11.2011 12:08, Thomas Steinmaurer wrote:
Or more object type bound, e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE OWNER TO ...
+1, although I'd prefer SET instead of CHANGE. And I believe that CREATE
OR ALTER should miss this clause.
Dmitry
30.11.2011 12:24, Mark Rotteveel wrote:
Is it able to discern between 32 and 64 bit?
Unfortunately, not.
On Windows Vista 64 bit (using Firefox 32 bit though)
I get the suggestion to download the Firebird 32 bit package.
This is the lesser evil. You know that 32-bit builds can work in both
On 11/30/11 12:33, Dmitry Yemanov wrote:
30.11.2011 12:24, Mark Rotteveel wrote:
Is it able to discern between 32 and 64 bit?
Unfortunately, not.
On Windows Vista 64 bit (using Firefox 32 bit though)
I get the suggestion to download the Firebird 32 bit package.
This is the lesser evil.
Hello, Alex!
Wednesday, November 30, 2011, 12:44:50 PM, you wrote:
AP Who knows which evil is lesser...
AP If one downloads 32-bit build for 64-bit OS, he can always stay with it
AP even not knowing that 64 builds exist.
I think this is design flaw of sf.net, and that's it.
Personally, I'd
30.11.2011 12:44, Alex Peshkoff wrote:
Who knows which evil is lesser...
If one downloads 32-bit build for 64-bit OS, he can always stay with it
even not knowing that 64 builds exist.
But at least it will work fine for him, even being possibly a bit slower
than the x64 build. And those who
On Wed, Nov 23, 2011 at 12:37 PM, Pawel Sawicki wa...@poczta.onet.pl wrote:
Hi All,
We are running Firebird-2.5.1 on virtual machine with RHEL6.0. Our
hypervisor is KVM. From time to time we get Firebird unresponsive and we
need to restart it. This situation occurs on heavy loaded system,
30.11.2011 9:08, Thomas Steinmaurer wrote:
Or more object type bound, e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE OWNER TO ...
etc..
ALTER PROCEDURE ... DROP SOURCE;
I have no idea if the SQL standard suggests here something.
I agree with changing owner, but
On 11/30/11 14:39, Dimitry Sibiryakov wrote:
30.11.2011 9:08, Thomas Steinmaurer wrote:
Or more object type bound, e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE OWNER TO ...
etc..
ALTER PROCEDURE ... DROP SOURCE;
I have no idea if the SQL standard suggests here
On 11/30/11 13:50, Adriano dos Santos Fernandes wrote:
On 30/11/2011 03:53, Alex Peshkoff wrote:
On 11/30/11 02:42, Frank Ingermann wrote:
DROP SOURCE OF [procedure name|trigger name|*]
or
CHANGE OWNER OF [db object|*] TOnew_owner
This approach looks much better than use of system
Allow DefaultDbCachePages more than 131072 pages.
-
Key: CORE-3678
URL: http://tracker.firebirdsql.org/browse/CORE-3678
Project: Firebird Core
Issue Type: Improvement
Components:
30.11.2011 12:17, Alex Peshkoff wrote:
BLR remains.
Weren't you going to get rid of it someday?..
Btw, I also do not like practice of dropping the sources. People use it
as a kind of protection for the database. This protection is not efficient.
But if users need that feature I can better
internal gds software consistency check (limbo impossible (184), file: vio.cpp
line: 2036)
--
Key: CORE-3679
URL: http://tracker.firebirdsql.org/browse/CORE-3679
30.11.2011 12:27, Carlos H. Cantu wrote:
APDROP SOURCE OF [procedure name|trigger name|*]
+1
May I suggest to borrow a term from Oracle and add clause WRAPPED to
CREATE or ALTER?
I.e create wrapped procedure as ... or create procedure aaa wrapped
as
It would make migration
30.11.2011 12:08, Thomas Steinmaurer wrote:
Or more object type bound, e.g.:
ALTER TABLE ... CHANGE OWNER TO ...
ALTER VIEW ... CHANGE OWNER TO ...
+1, although I'd prefer SET instead of CHANGE. And I believe that CREATE
OR ALTER should miss this clause.
+1 That sounds very familiar
EXECUTE BLOCK statement and ISC_DSQL_EXECUTE2() problem.
Key: CORE-3680
URL: http://tracker.firebirdsql.org/browse/CORE-3680
Project: Firebird Core
Issue Type: Bug
On 30/11/2011 14:52, Björn Reimer wrote:
The discussion about removing sources or not makes little sense for
me. It is possible with fb 2.5 and prior and should be possible in
future versions as this feature is used. If you don't like it don't
use it.
I wonder if these people who is
AdSF With BLR + debug_info it's very possible (and easy) to reconstruct
AdSF sources. And better, you don't even need to read the sources in the
AdSF original format style, but in the style you you want it!
Probably not, but what you call easy probably is not true for 99% of
the standard FB
On 30/11/2011 16:05, Carlos H. Cantu wrote:
AdSF With BLR + debug_info it's very possible (and easy) to reconstruct
AdSF sources. And better, you don't even need to read the sources in the
AdSF original format style, but in the style you you want it!
Probably not,
So as I suppose.
but
At 10:50 PM 30/11/2011, Adriano dos Santos Fernandes wrote:
On 30/11/2011 03:53, Alex Peshkoff wrote:
On 11/30/11 02:42, Frank Ingermann wrote:
DROP SOURCE OF [procedure name|trigger name|*]
or
CHANGE OWNER OF [db object|*] TOnew_owner
This approach looks much better than use of system
AdSF If anyone write it and distribute it, it's easy for anyone. And it's not
AdSF difficult to write it.
Maybe it is not difficult for core developers, but I don't think any of
you will spend time with such thing, uh?
Things will get better when crypto plugins and local users becomes a
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
user without any rights can delete sequences, collations and even triggers with
rdb$system_flag=0
-
Key: CORE-3681
URL:
Hi Helen e.a.,
Am 30.11.2011 19:32, schrieb Helen Borrie:
On 11/30/11 02:42, Frank Ingermann wrote:
DROP SOURCE OF [procedure name|trigger name|*]
or
CHANGE OWNER OF [db object|*] TOnew_owner
snip
I don't think bloat the language with non-standard syntax for
non-mainstream tasks is a
-Original Message-
From: Frank Ingermann [mailto:fr...@fingerman.de]
Sent: Miércoles, 30 de Noviembre de 2011 19:32
Still i think it's a no-go to just take the ability _away_ to
clear out those sources. It IS common practise.
I don't see any reason to forbid it either. Let's see
Hi Claudio,
From: Frank Ingermann [mailto:fr...@fingerman.de]
Still i think it's a no-go to just take the ability _away_ to
clear out those sources. It IS common practise.
snip
(+1 for the COMMENTs!)
The problem is that we lack equivalent commands for sources and debugging.
Then if we
On 16-11-2011 22:39, Frank Ingermann wrote:
Hi all,
i'm trying to combine the new Window functions in Fb3 with
recursive CTEs to get a _defined_ ordering of the recursive
child records in the result set.
The recursive problem is fixed, in fact it was a problem of window
functions with
28 matches
Mail list logo
