> Changing gbak so it backs up user enhancements to the system tables is just
> programming, and restoring them after the base table are created isn't hard,
> but both go against the V3 goal of shutting users out of system space.
It depends on your view/definition of "system space" or "system ob
On Thu, Apr 3, 2014 at 2:06 PM, Claudio Valderrama C. wrote:
>
>
>
> AFAIK, you can put triggers on sys tables and they last until the last
> attachment finished. When the db is loaded again, those triggers do not
> load. I don't know if that changed recently, but was this way since I
> remember.
> -Original Message-
> From: Leyne, Sean [mailto:s...@broadviewsoftware.com]
> Sent: Domingo, 30 de Marzo de 2014 14:31
> To: For discussion among Firebird Developers
>
> Claudio,
>
> > To the dismay of Sean, I continue saying that while we
> don't declare "name
> > independence" and co
Claudio,
> To the dismay of Sean, I continue saying that while we don't declare "name
> independence" and continue relying on RDB$ for some decisions, it's better
> to forbit the RDB$ prefix for user objects. See, for example:
That is not want I was/am saying.
I have problem with forbidding RDB$
The wolf in Manchester pleads not guilty. A cursory examination of the
Vulcan code exposed the following code snippet in MET_lookup_index_name:
if (!gen_id) {
strcpy (name, "RDB$GENERATORS");
return;
}
Any student of wolf-code will understand that the wo
Oedipus found the sphinx near Thebes and the monster asked:
"what is the thing that cannot be seen but can be called by name to change
it?"
Oedipus replied "it's RDB$GENERATORS" and the sphinx committed suicide.
Now if we replace the sphinx by a wolf, the wolf at Massachusetts asks:
"in the releas
