Sorry if this is a dup, Yahoo did something weird…
Looking at my production system I see that I have an FDB file and an
FDB.delta. The date of the FDB is May 2nd, 2013. The date of the delta is today.
I believe that this is the reason I cannot directly connect to the FDB file on
my new s
> Looking at my production system I see that I have an FDB file and an
> FDB.delta. The date of the FDB is May 2nd, 2013. The date of the
> delta is today.
These are just 2 separate databases. Firebird does not require a
special extension, ".fdb" ist just the usual extension to use.
>From the nam
Whoa, this is interesting...
My first attempt to move the DB was to simply copy over the FDB. That didn't
work, so that's when I went down the nbackup rabbit hole. As it turns out,
nbackup is the problem, not the solution...
When I tried to re-attach the FDB file on the new server I got a "file
Hello Maury,
> When I tried to re-attach the FDB file on the new server I got a "file not
> found" error. But looking in some of the logging files I found...
>
> Reason: I/O error for file CreateFile (open)
> "D:\FISHBOWL\DATABASE\DATA\ASSOLAR.FDB.delta"
> Error while trying to open file
> null
On 2014-01-16, at 10:11 AM, Paul Vinkenoog wrote:
>
> What exactly are you missing in the documentation? Notice that delta
> files are normally very short-lived.
That's the issue right there. As it is clearly possible that these are not
*always* short lived, this should be mentioned along with
Maury Markowitz wrote:
> > What exactly are you missing in the documentation? Notice that delta
> > files are normally very short-lived.
>
> That's the issue right there. As it is clearly possible that these are not
> *always* short lived, this should be mentioned along with suggestions on what
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 se
>
> 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 manipul
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 ther
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
On Fri, Jan 17, 2014 at 6:52 AM, Maury Markowitz
wrote:
>
> 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 vend
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 increment
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
Hello Sean,
> > 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
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 ma
>> 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 (d
Stefan Heymann wrote:
> > It also requires you to stop the server, which may be a nuisance if
> > there are also other databases in use.
>
> AFAIK, after a FULL shutdown you can also access the .fdb file on a
> file basis. So you don't have to stop the entire service.
You're right; in Firebird 2.
17 matches
Mail list logo
