25.06.2013 12:01, remk_1 wrote:
what is the current estimation of FB 2.5.3 release timeframe ? There is
already a substantial amount of bug fixes since 2.5.2, some of them seem
important.
July-August.
Dmitry
Shadow Firebird
Regards,
please and remove the shadow of my Firebird database, thanks.
[Non-text portions of this message have been removed]
Dear Friends,
We have a strange problem with GBak. We make a backup with gbak and then a
restore, also with the same.
We have a table with 60 rows where a not null type SmallInt column has 0 (zero)
as content.
When restoring, GBak returns null for this column. As this column is not null,
Hello, I think you have a row with null value. The option is update table
set column = 0 where column is null and then try to backup restore. I have
seen this issue when changing columns from null to not null and you have
rows in the table.
2013/6/25 Tupy... nambá anhangu...@yahoo.com
**
Hello, Tupy...!
Tuesday, June 25, 2013, 11:23:47 PM, you wrote:
Tn Dear Friends,
Tn We have a table with 60 rows where a not null type SmallInt column has 0
(zero) as content.
Tn When restoring, GBak returns null for this column. As this column
Tn is not null, we get an error message (Error:
Em 25/6/2013 16:23, Tupy... nambá escreveu:
Dear Friends,
We have a strange problem with GBak. We make a backup with gbak and then a
restore, also with the same.
We have a table with 60 rows where a not null type SmallInt column has 0
(zero) as content.
When restoring, GBak returns
Señor Garcia,
Gracias por su retorno.
If I understood well, you say to make a first insertion at this table, manually
apply values to the columns of this table, save the values to the table, delete
this line and then restore the table. It´s a possible solution, but not a
pratical. Specially
Hi, Dmitry,
Thanks for you response.
No one has changed this table. At most, as a not null column, someone could
have change it to another value, but not to null. And no one changed it´s
validation rule (as not null). This is discarded.
We repeated the action = we take the DB, checked the
Mr.Benson,
No, the constraint wasn´t change. As I explain to mr.Jesus Garcia, we take the
DB having the data and the constraint in the needed conditions, we made a
backup and then the restore. This mean = all the conditions were assured that
the DB were in good conditions and, during the
Thanks, Looks like it is working now. Appreciate your guidance
- Original Message -
From: Tupy... nambá
To: firebird-support@yahoogroups.com
Sent: Tuesday, June 25, 2013 2:23 PM
Subject: [firebird-support] GBak Backup Restore Problem
Dear Friends,
We have a
Hello, Tupy...!
Wednesday, June 26, 2013, 12:07:07 AM, you wrote:
Tn backup and then the restore. This mean = all the conditions were
Tn assured that the DB were in good conditions and, during the
backup/restore process, the
Tn data at this column was lost.
The funny thing is that gbak is not
Dmitry,
Yes, the problem seems incredible. If I heard it from someone else, I would
also have difficult to believe on that. But this is as it is !
I will not repeat (ooops, I am already in the way !) that the source DB (for
the backup) is ok. And the backup, as only could be, really has the
Sorry, Softtech, I didn´t understand your message, since I still want to
understand what happened.
From: Softtech Support stwiz...@att.net
To: firebird-support@yahoogroups.com
Sent: Tuesday, June 25, 2013 5:13 PM
Subject: Re: [firebird-support] GBak Backup
Hello, Tupy...!
Wednesday, June 26, 2013, 12:35:34 AM, you wrote:
Tn I will not repeat (ooops, I am already in the way !) that the
Tn source DB (for the backup) is ok.
currently no evidence that it is ok :-)
Tn GBak ! This mean = or the problem happens at the backup process, or during
the
At 08:56 a.m. 26/06/2013, Dmitry Kuzmenko wrote:
Tn I will not repeat (ooops, I am already in the way !) that the
Tn source DB (for the backup) is ok.
currently no evidence that it is ok :-)
The gbak restore problem IS evidence that the source DB is not OK. This problem
could have been lying
Roberto,
Em 25/6/2013 17:07, Tupy... nambá escreveu:
Mr.Benson,
No, the constraint wasn´t change. As I explain to mr.Jesus Garcia, we take
the DB having the data and the constraint in the needed conditions, we made a
backup and then the restore. This mean = all the conditions were
16 matches
Mail list logo
