-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Martes, 06 de Mayo de 2014 15:41
After successfully recovering a transaction that way, the current
implementation in Jaybird deletes the entry in RDB$TRANSACTIONS
(probably as a form of house-keeping, or
Hi,
just for information, seems that some last commit broke something in gbak :
sudo /opt/firebird/bin/gbak -c /home/vagrant/fbtest.fbk
localhost:/home/vagrant/fdb/test/fbtest30.fdb -user SYSDBA -password
masterkey
gbak: ERROR:DELETE operation is not allowed for system table
RDB$DEPENDENCIES
-Original Message-
From: Philippe Makowski [mailto:pmakow...@ibphoenix.fr]
Sent: Miércoles, 07 de Mayo de 2014 3:05
just for information, seems that some last commit broke
something in gbak :
sudo /opt/firebird/bin/gbak -c /home/vagrant/fbtest.fbk
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Martes, 06 de Mayo de 2014 15:41
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
2) Is there an alternative
-Original Message-
From: Philippe Makowski [mailto:pmakow...@ibphoenix.fr]
Sent: Miércoles, 07 de Mayo de 2014 3:05
Hi,
just for information, seems that some last commit broke
something in gbak :
sudo /opt/firebird/bin/gbak -c /home/vagrant/fbtest.fbk
06.05.2014 10:54, Dmitry Yemanov wrote:
Transaction should be invalidated
Is line tra_flags |= TRA_invalidated enough for that or something more
should be done
for transaction invalidation?
--
WBR, SD.
--
Is
07.05.2014 13:12, Dimitry Sibiryakov wrote:
Is line tra_flags |= TRA_invalidated enough for that or something more
should be done
for transaction invalidation?
Enough, AFAIK.
Dmitry
--
Is your legacy SCM system
06.05.2014 18:32, Dimitry Sibiryakov wrote:
AFAICS further DML operations are allowed in invalidated transaction.
Shouldn't
ROLLBACK to be the only permitted action?
I would say that it makes sense to reject further DML, as it cannot be
committed anyway. I'm not insisting on that though.
07.05.2014 11:49, Dmitry Yemanov wrote:
Enough, AFAIK.
Ok, done.
--
WBR, SD.
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
I assume
On Wed, 7 May 2014 05:00:43 -0400, Claudio Valderrama C.
cva...@usa.net
wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
2) Is there an alternative to removing this information?
Mark, I had
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
I was a bit wrong - when
On 7-5-2014 20:54, Vlad Khorsun wrote:
On Wed, 7 May 2014 09:38:16 +0300, Vlad Khorsun wrote:
This leads me to the questions:
1) When are prepared or rolled back transactions removed from
RDB$TRANSACTIONS? Or are they kept indefinitely?
Its never removed. And i see no problem with it.
-Original Message-
From: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
Sent: Miércoles, 07 de Mayo de 2014 8:14
As the value of RDB$TRANSACTION_STATE is modified, I assume
this code (or
something very similar) is actually called, but then the `else` branch
shown above. What does
14 matches
Mail list logo
