I installed firebird database for the first time in my life (version 1.5.6 on Windows 7), after installation I can not connect to the sample database (employee.fdb exists), or create a database. This gives the following error in ISQL Tool:
C:\Program Files\Firebird\Firebird_1_5\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> CONNECT "C:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb"
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
SQL> create database 'C:\test.fdb'
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
Firebird 1.5 was written (long) before Windows 7, and before things like UAC existed. It may simply be that Firebird 1.5 doesn't work correctly with Windows 7, or that it requires additional effort to work. I'd suggest to install Firebird 2.5.2 (update 1) as that is the latest version and is known to work with Windows 7.
Another problem might be that local system connections don't work as I seem to remember that Firebird 1.5 uses an older local protocol which doesn't work on newer Windows versions. This protocol was replaced in Firebird 2.0. To workaround that you need to include the hostname in the CREATE DATABASE or CONNECT statement, so for example:
create database 'localhost:C:\test.fdb' user 'SYSDBA' password 'masterkey';
Windows 7+ breaks the local api protocol. You have to use Tcpip protocol to connect to the database, even for local connections.
Related
I encountered the error when I used below the script on Postgres 13.9 (oracle_fdw 2.4) on Windows 10 64-bit.
CREATE SERVER yf FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver 'yf');
CREATE USER MAPPING FOR postgres SERVER yf OPTIONS (user 'yonker', password 'his');
GRANT USAGE ON FOREIGN SERVER yf TO postgres;
SELECT oracle_diag('yf');
[HV00N]: ERROR: error connecting to Oracle: OCIAttrSet failed to set driver name in session handle
detail：ORA-24315: illegal attribute type
I can connect to oracle server with tnsname 'yf' using sqlplus.
oracle client 10.2.0.4
oracle server 11.2.0.4
The documentation states the requirements:
Oracle client version 11.2 or better is required.
The error is thrown when oracle_fdw tries to set OCI_ATTR_DRIVER_NAME on the session handle, which was not available before Oracle 11. It is no problem to use an older Oracle server version, as long as you are using a less outdated client version.
I'm trying setup Firebird 2.5 with FlameRobin 0.9.3, installed on Windows 10 64bit. The .fdb files are on the same disk of the Firebird machine and the FlameRobin program.
I'm trying to connect EMPLOYEE.FDB file with FlameRobin getting this error.
My settings for this database file below.
I never changed my sysdba password. Is it due to this error ODBC driver?
Edit: I've created a new database on ISQL to try. Username: SYSDBA Password: 31202333
But I am getting same error on FlameRobin.
The error means that your username does not exist (unlikely for SYSDBA), or the password is incorrect*. In Firebird, passwords are system wide, not per database. Check your password (default installations of Firebird on Windows use the password 'masterkey'). Otherwise try resetting the password using gsec.
The fact it might work with ISQL, is that you're using a local path, which may cause ISQL to use Firebird embedded mode, and in embedded mode on Windows, the password is ignored (on the assumption that if you have filesystem access to the database file, you are allowed to open database). I guess that, if instead of 'D:\sq\sample.fdb', you'd use 'localhost:D:\sq\sample.fdb' in ISQL, you would get the same error as in FlameRobin.
*: In Firebird 3 and later it can also mean that the user does not exist for the authentication plugins tried, even though the user may exist for a different authentication plugin.
When I execute Firebird 3.0.x backup command:
c:\Db>"C:\Program Files\Firebird\Firebird_3_0\gbak.exe" -b c:\Db\Db1.fdb c:\Db\Db1_backup.fbk -garbage_collect -transportable -verify -user SYSDBA -pas PASSWORD
Error 1 happend:
gbak: ERROR:I/O error during "CreateFile (open)" operation for file "C:\DB\DB1.FDB"
gbak: ERROR: Error while trying to open file
gbak: ERROR: The process cannot access the file because it is being used by another process.
gbak:Exiting before completion due to errors
Example 2 with TCP/INET/localhost/remote protocols:
c:\Db>"c:\Program Files\Firebird\Firebird_3_0\gbak.exe" -backup inet://c:\Db\Db1.fdb d:\_Backups\Db1_20180702_230546.fbk -garbage_collect -transportable -verify -skip_data SOMETAB_TO_SKIP -user SYSDBA -password PASSWORD123
Error 2 happend:
gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
First of all ... to be honest I am not sure when this started or why. I did not look at my server maybe 3 months but today my backup disk broke down so I had to. I just saw this error first time today and I lived in conviction that my backup works. But I had Firebird 2.5 before.
The question is: is this specific only for Firebird 3 SuperServer on Windows? And there is no way how to backup Firebird 3 SuperServer database when is used by FB server?
Tested and failed on Firebird server 3.0.2 and 3.0.3 on Windows Server 2016.
Firebird is running as a service
Nothing is changed in firebird.config except:
WireCompression = true
RemoteServicePort = 1234
CpuAffinityMask = 8
ServerMode = Super or SuperClassic (when I testing it)
When I execute first command on SuperClassic it works.
When I execute first command on SuperServer 2.5.x it works.
Ok, so I finally figured out where is the issue. Here is the explanation:
My password is wrong!
BUT!
When I use SuperClassic I can use WRONG password and Firebird allows access to the database. (as local user)
When I use SuperServer I can use WRONG password and Firebird allows access to the database WHEN I am the FIRST connection! (as local user with and also without remote protocols)
When I use SuperServer and I use WRONG password Firebird denied access to the database WHEN I am the second (and more) connection! (local also remote user)
With only remote protocols you can not access database with wrong password.
(By remote protocols I mean this.)
This are the reasons of the differences in behavior and why I did not see using of WRONG password. Thanks to everybody who tried to help me.
I am trying connect to firebird 3.0 throught latest version of ADO.NET provider 5.0.5.0 from my simple test .net application. When i used sysdba user connection is made OK, but if i used other user then connection failed with classic FBException :
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
"initial catalog=c:\\Database\\Data.fdb;data source=localhost;user id=sysdba;password=sysPass;port number=3050" = OK
"initial catalog=c:\\Database\\Data.fdb;data source=localhost;user id=michal;password=micPass;port number=3050" = failed
But if i am trying connect throught IBExpert or isql , then connection is made OK and i can get data from tables.
Previously i used Firebird 2.1 and then i upgraded to Firebird 3.0 superclassic and get ADO.NET provieder from nuget.Actually i do not need SRP ecryption so I disabled WireCrypt etc. and use Legacy authentication (Firebird 3.0 release notes page 117). Then i created my new user via IBExpert (sysdba was created during installation firebird server).
I do not need migrate users from previous firebird version so I skiped Upgrading a v.2.x Security Database steps.
It is strange that i can connect myUser via IBExpert or isql, but not via ADO.NET provider.
It seems to me unlikely that ADO.NET provider has bug of this type (everyone needed connect via user), so I guess that i have some bad configuration.
I had some bad configurations and I need set correctly:
In firebird.conf, there has to be: WireCrypt = Enabled (not disabled)
Create user account older way (in my case via IBExpert)
The password have to max. length 8 chars (previously you can have more chars and Firebird is omit)
I'm trying to setup a local firebird instance to test against but am unable to connect to it with even ISQL. I have tried to following by following the quick start guide here:
CONNECT ..\examples\empbuild\employee.fdb user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 08001
unavailable database
After some searching I tried modifying that to:
CONNECT "localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb" user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 28000
cannot attach to password database
After confirming I had the right directory path I decided to give on on connecting for now and try creating a new DB:
SQL>CREATE DATABASE 'C:\data\test.fdb' page_size 8192
CON>user 'SYSDBA' password 'masterkey';
Which also gave me the error:
Statement failed, SQLSTATE = 08001
unavailable database
Are there any common pitfalls I might be hitting? I've also tried the commands above both with and without the firebird service running. Also is there a detailed reference on the SQLSTATE codes?
As already mentioned in my comments the problem is caused by running the Firebird server as an application. Firebird has its password database (security2.fdb) in C:\Program Files\Firebird\Firebird_2_5. As this database is (almost, but not entirely) a normal Firebird database, the server requires write access to this database (for the transactions, etc).
By default (with UAC) users do not have write access to the password database, so this requires elevation to Administrator. So access to Firebird requires that you either run the application as a service with sufficient rights (eg as done by the default installer), or when running the server as application to run it 'As administrator'. Another option is to not install it in Program Files.
This BTW applies double when accessing the example employee database as this database file is also located in the Program Files folder.
This is for macOS/OSX (mine is 10.15) firebird ver 2.5 users.
The installation process here does not ask for a sysdba password. Which means: the security database 'security2.fdb' does not exist after a new installation.
This seems to be intentionally for security reasons since > ver 2.5.
To create one, we use the demo database as a helper:
open sql as su: >sudo isql (we don't have user rights on dir)
Connect to a existing db:
sql>connect
"/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
" user 'SYSDBA' password 'masterkey';
Now we created the missing file 'security2.fdb' in the folder:
"/Library/Frameworks/Firebird.framework/Resources/English.lproj/var/"
(jro)