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
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
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
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
I am a admin of the Fishbowl Inventory (FBI) system for our company, which is a
Java app on top of Firebird.
I need to move the system off an unstable machine. FBI does not allow me to
simply replace the .FDB files, for reasons that have not been explained (error
codes that make no sense). I
On 2014-01-15, at 2:02 PM, Hugo Eyng wrote:
I am not sure if i understood your question.
You want to move the fdb file to another computer?
That is correct.
For reasons that I do not understand, the simple method of simply copying the
FDB from one machine to another does not work. When I
On 2014-01-15, at 2:43 PM, Alexandre Benson Smith wrote:
Take a look on nbackup (http://www.firebirdsql.org/manual/nbackup.html)
manual so you could try to merge it back manually.
Indeed, but that brings me back to the actual problem... I do not know the
password for SYSDBA, and the only
On 2014-01-15, at 2:43 PM, Alexandre Benson Smith wrote:
Take a look on nbackup (http://www.firebirdsql.org/manual/nbackup.html)
manual so you could try to merge it back manually.
But wait... what about...
ALTER DATABASE END BACKUP
If I am reading it correctly, this appears to do the same
On 2014-01-15, at 4:29 PM, Paul Vinkenoog wrote:
Why don't you contact the administrator of the system in question? After
all, *someone* should know the SYSDBA password, shouldn't they?
I don't believe so. The installer process that created the DB, which comes from
Fishbowl, not Firebird,
On 2014-01-15, at 6:31 PM, Paul Vinkenoog wrote:
The date of the FDB is May 2nd, 2013. The date of the delta is today.
...combined with his later statement that the system's Scheduler
function, without any warning or errors, stopped making these nbackups
last May.
Indeed. Perhaps file
On 2014-01-15, at 5:40 PM, hv...@users.sourceforge.net
hv...@users.sourceforge.net wrote:
This is too strong statement. To verify it we need to know physical backup
state of the database. gstat -h will show it (and it not requires admin
privileges).
I am able to run this on the original
On 2014-01-15, at 8:23 PM, Paul Vinkenoog wrote:
I think you should contact Fishbowl Inventory support to clear this up.
Indeed; they currently have a multi-hour phone wait time.
Most keep it at masterkey though. In your case, I assume that the
Fishbowl software has generated a secure
On 2014-01-15, at 8:23 PM, Paul Vinkenoog wrote:
I think you should contact Fishbowl Inventory support to clear this up.
So a little Google-fu was all that took. Now armed with the credentials, what
would be the next steps at this point?
I suspect the next step is to END BACKUP. However, I
I'm trying to retrive the number of rows from a query passed in via ODBC. Not
much to it...
if (!SQL_SUCCEEDED(SQLRowCount(odbcStmt, (SQLLEN *)rowCount))) {
rowCount = 0;
}
This works for most providers, but returns -1 on Firebird. Is there another
call I
On 2012-06-16, at 5:00 PM, Helen Borrie wrote:
The name of the database is employee.fdb not employees.fdb.
Which doesn't work either. Same error. The error remains the same no matter
what you try to open:
Statement failed, SQLSTATE = HY000
Can't access lock files' directory /tmp/firebird
I'm testing my FB install using isql and the employee.fdb database...
Maurys-MacBook-Air-2:bin maury$ ./isql
localhost:/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employees.fdb
Statement failed, SQLSTATE = HY000
Can't access lock files' directory /tmp/firebird
Use CONNECT
I've been muddling my way through a build of the ODBC driver on OSX. After some
work I was able to find and build all the required prerequisite files, change
some paths, move a few things around, and presto, one Mac driver. However,
attempting to connect using it fails with:
Can someone suggest a simple ODBC-based text-based query interface for the Mac?
I'm using RazorSQL, but it's based on JDBC and its more than it should be.
On 2012-06-06, at 11:22 AM, mariuz wrote:
you can use isql from unixodbc
I have installed it on ubuntu linux so it should be possible to work on
macosx too
http://www.firebirdnews.org/?p=1324
I found an installer-based version of this, which appears to have installed a
DSN editor and
I would like to test the transition from 2.x to 2.5 on a backup machine we
have. Am I correct in believing I can simply move the data files over and point
the 2.5 server at them?
The only note I found on this was this:
http://www.firebirdnews.org/?p=5027
Which appears to detail problems in
By the way, I don't know if this is important or not, I can access the DB fine
through MSQuery and the DSN I set up. From within the same Excel instance.
On 2012-05-03, at 11:34 AM, Thomas Steinmaurer wrote:
Open Windows Task Manager. On Windows 64-bit. If you see a *32 behind
the process name, then it is 32-bit, otherwise 64-bit.
It is 64 bit.
That *suggests* that I'm using the correct driver, installed from
Firebird_ODBC_2.0.0.150_x64.exe
On 2012-05-03, at 11:51 AM, Bart Smissaert wrote:
Here are various ODBC connection strings for Firebird:
http://www.connectionstrings.com/firebird
No joy. I tried them all, they all fail with the same useless error message.
On 2012-05-03, at 11:59 AM, Bart Smissaert wrote:
The driver box says IscDbc.
That is not a file name as far as I know.
The file I have is C:\WINDOWS\system32\OdbcJdbc.dll
So I went to the System32 folder… but are we not talking about 64bit stuff? Do
they put 64bit stuff in System32?!
On 2012-05-03, at 12:49 PM, Leyne, Sean wrote:
Let's start by setting up an ODBC DSN -- we will use that to ensure that the
basic connectivity is working.
When you press the Test button on the ODBC DSN want happens?
It works perfectly.
And that DNS also works perfectly in iSQL and many
On 2012-05-03, at 12:56 PM, Bart Smissaert wrote:
Yes, I have tried calling the DSN from the connection string in VBA
Can you show that exact connection string?
conn.Open DSN=Fishbowl;, GONE, FISHING
Wait wait wait… is there a possibility that I'm using the wrong ADO inside
Excel? Is
Oh, I think this might be in. According to some forum posts over on MS Live
(love that name!) ADODB does not run under 64-bit. Sweet!
Chime in if you're using ADO on 64-bit Excel, this post might just be wrong.
According to the same post, there are other technologies I might have to use,
but
Well one way or the other the latency of the link does seem to be the most
important factor in the problem I'm seeing.
I have three ways to get at the data:
1) log into the remote server using RDP and run the queries locally. even the
most complex ones complete in under a second
2) use JDBC
28 matches
Mail list logo
