Re: [firebird-support] Confused about delta files [SOLVED]
On 2014-01-16, at 8:30 PM, Paul Vinkenoog wrote: In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location. Now *that's* interesting, because this has been the most suggested method I have seen. In fact, I only learned about the nbackup method long after having done two moves the other way, which was the recommended method from the vendor. I think maybe it would be a good idea to put this into the vendor's dox as well.
RE: [firebird-support] Confused about delta files [SOLVED]
In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location. What? Is there more to knowing that if you stop the fbserver, it's safe to copy an .fdb file than there is to know how to manipulate a database file under the control of nbackup? I think not Alan
Re: [firebird-support] Confused about delta files [SOLVED]
Alan McDonald wrote: In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location. What? Is there more to knowing that if you stop the fbserver, it's safe to copy an .fdb file than there is to know how to manipulate a database file under the control of nbackup? Sorry, I'm not sure what you mean by this (maybe because English isn't my first language). Of course it's safe to copy an .fdb if the server is down (and no embedded connections exist), but the standard mantra is use gbak, simply because this is *always* safe. Paul Vinkenoog
Re: [firebird-support] Confused about delta files [SOLVED]
Maury Markowitz wrote: In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location. Now *that's* interesting, because this has been the most suggested method I have seen. In fact, I only learned about the nbackup method long after having done two moves the other way, which was the recommended method from the vendor. That recommendation makes sense, especially since gbak has been around for a long time and is known to do its job. Nbackup is relatively new; it ought to be just as safe as gbak but in your case, something went wrong; the database wasn't unlocked and the .delta not re-integrated. Even then, the database kept functioning and I assume (and hope for you) that no data were corrupted. I think maybe it would be a good idea to put this into the vendor's dox as well. You mean the FishBowl docs? Or the Firebird docs? BTW, this nbackup scheme you used: did it come with Fishbowl or did you set it up yourself? Paul Vinkenoog
Re: [firebird-support] Confused about delta files [SOLVED]
On Fri, Jan 17, 2014 at 6:52 AM, Maury Markowitz mmarkow...@assolarinc.comwrote: Now *that's* interesting, because this has been the most suggested method I have seen. In fact, I only learned about the nbackup method long after having done two moves the other way, which was the recommended method from the vendor. Gbak is a backup/restore program that produces an architecture agnostic backup file. The backup file contains a logical representation of the format and contents of the database. Nbackup is a fast physical backup that supports incremental backups. Nbackup is not a database transport mechanism. If you found documentation that suggests using Nbackup as a transport, the Firebird Documentation group should know about it, because neither the database file nor the delta is architecture independent. Good luck, Ann
Re: [firebird-support] Confused about delta files [SOLVED]
On 2014-01-17, at 2:33 PM, Ann Harrison wrote: Gbak is a backup/restore program that produces an architecture agnostic backup file. The backup file contains a logical representation of the format and contents of the database. Nbackup is a fast physical backup that supports incremental backups. Nbackup is not a database transport mechanism. If you found documentation that suggests using Nbackup as a transport, the Firebird Documentation group should know about it, because neither the database file nor the delta is architecture independent. No, sorry, I meant to say that every reference I have ever found has suggested the correct way to move a FB database from one machine to another is to simply copy the FDB file while the server is down. However, in my case, the presence of the failed nbackup meant that the delta file it left behind also had to be copied. I'm actually surprised that simply copying both files actually solved the problem, but I suppose it did so because the original FDB had some sort of pointer to the existence of the delta. This is definitely *not* something that the documentation covers. Actually, from your post it would seem that the whole concept of simply coping the FDB is a bad idea anyway, and the proper solution would be to always use gbak?
RE: [firebird-support] Confused about delta files [SOLVED]
Paul, In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location. That is no longer true for most uses (as long as the engine has been stopped), it is true if moving across CPU platform/endian (ie x86/x64 to Sparc). You can move a db between x86/64 Windows and x86/64 Linux without any concern -- we do it all the time. Sean
Re: [firebird-support] Confused about delta files [SOLVED]
Maury Markowitz wrote: No, sorry, I meant to say that every reference I have ever found has suggested the correct way to move a FB database from one machine to another is to simply copy the FDB file while the server is down. Oops, that's not good advice. Although this may be safe, it may also not be (depending on platform, possibility of embedded connections, etc.) It also requires you to stop the server, which may be a nuisance if there are also other databases in use. Did you find this advice in any docs that came from the Firebird project itself? However, in my case, the presence of the failed nbackup meant that the delta file it left behind also had to be copied. I'm actually surprised that simply copying both files actually solved the problem, but I suppose it did so because the original FDB had some sort of pointer to the existence of the delta. This is definitely *not* something that the documentation covers. No, but it doesn't really need to. First, it is an implementation detail, and second, it goes without saying that if all modifications are sent to the delta, Firebird knows that if the main database is in nbak state, it also needs the delta. The default name is database file name.delta, but you can set another path + name in the database itself (and this is something that the manual *does* cover). Actually, from your post it would seem that the whole concept of simply coping the FDB is a bad idea anyway, and the proper solution would be to always use gbak? If in any doubt, use gbak. But as you can tell from Sean's post, there are situations where a straight file copy/move is just as safe. Just make sure you know what you are doing. Cheers, Paul Vinkenoog
[firebird-support] RE: Full Cross Tab but unknown column headers
Hi Walter If it not a bother can we revisit this issue of Malformed String of ACTUALIZAR_TABLA_PIVOT. I start and end the CREATE PROCEDURE... a follows: SET TERM ^ ; CREATE PROCEDURE ACTUALIZAR_TABLA_PIVOT( . lcInto1; EXECUTE STATEMENT lcActualizar; END END^ SET TERM ; ^ I get the malformed string error. The last END is copied from your txt link for this procedure. I have to put the ^ to this END so that I can complete the SET TERM and malformed is the issue But if I change it to the following the error changes EXECUTE STATEMENT lcActualizar; END END ^ SET TERM ; ^ Unexpected end of command - line 92 column 4 which is the start of the last END. Does this help any? Is there some command that is missing from the original txt file online? Please advise Thanks and regards Bhavbhuti
