I just installed Firebird for Win64, and I was trying to connect to the employee database which comes pre-packaged with ISQL.
Following the steps from the Firebird official QuickStart Documentation I opened the ISQL utility and entered:
connect localhost:employee user sysdba password masterkey;
As a result I got:
Statement failed, SQLSTATE = 28000
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
Strangest thing is that if I navigate to the employee database sample itself and issue the isql command from there I can successfully connect.
The difference is that connecting directly to a database file doesn't require a password, it will even ignore the password, and just use the provided user to know which privileges to apply.
Without a hostname, ISQL will by default use Firebird embedded mode, and not the server. To compare, try using isql employee.fdb (or isql employee), it will just login with your current OS username, while isql localhost:employee will fail with a 'Your user name and password are not defined'.
It looks like you specified a different password than the default of masterkey, or somehow the sysdba account wasn't initialized. I recall there was a problem with the installer of an earlier Firebird 3 version, but I don't think 3.0.2 should be affected by this (or at least: it worked for me).
If the SYSDBA account wasn't initialized, then follow the steps of the Firebird 3 release notes, section Initializing the Security Database:
Initialization Steps
Initialization is performed in embedded mode using the isql utility.
For an embedded connection, an authentication password is not required
and will be ignored if you provide one. An embedded connection will
work fine with no login credentials and “log you in” using your host
credentials if you omit a user name. However, even though the user
name is not subject to authentication, creating or modifying anything
in the existing security database requires that the user be SYSDBA;
otherwise, isql will throw a privilege error for the CREATE USER
request.
The SQL user management commands will work with any open database.
Because the sample database employee.fdb is present in your
installation and already aliased in databases.conf, it is convenient
to use it for the user management task.
Stop the Firebird server. Firebird 3 caches connections to the security database aggressively. The presence of server connections may
prevent isql from establishing an embedded connection.
In a suitable shell, start an isql interactive session, opening the employee database via its alias:
> isql -user sysdba employee
Create the SYSDBA user:
SQL> create user SYSDBA password 'SomethingCryptic';
SQL> commit;
SQL> quit;
To complete the initialization, start the Firebird server again. Now you will be able to perform a network login to databases,
including the security database, using the password you assigned to
SYSDBA.
Where 'SomethingCryptic', should be your password.
If a SYSDBA user was created, you will need to change its password if you no longer remember what you set. Follow the same steps, but in step 3 do:
SQL> alter user SYSDBA set password '<new password>';
SQL> commit;
SQL> quit;
If this gives an error "record not found for user: SYSDBA", make sure you are really connected as SYSDBA, otherwise retry the original step 3. Not having admin access will behave as if the user doesn't exist, so the error is the same if the user really doesn't exist, or if you are connected with an unprivileged user.
CONNECT 'employee' user 'SYSDBA' password 'masterkey';
You need make sure that your alias.conf have something like this: employee=C:/examplepath/employee.fdb
make sure that the services of firebird is on
Related
I have database of firebird of more than 8 GB and I want to migrate all the data from it. But I have forgotten the username and password. Is there anyway or any tool through which I can crack this database and can get my data back?
In most Firebird setups, the username and password is kept in a central security database (security3.fdb in the case of Firebird 3). If you don't know the username and password of a user anymore, you have the following options.
Be aware, this answer uses Firebird 3 as its base, but most options also apply to Firebird 2.5 and earlier. Instead of security3.fdb, use security2.fdb. The create user and alter user steps only work in Firebird 2.5 or higher.
Use the sysdba account (or another user with RDB$ADMIN role in the security database) to reset the password of the user through any other database
Use gsec as SYSDBA in embedded mode to reset the password
Replace the security database with a copy with a known password for the user
If your database uses itself as its security database, you will first have to remove that setting from the databases.conf by commenting out the SecurityDatabase setting for that database.
For Firebird 3, this answer assumes the creation of a user for the Srp authentication mechanism, and the steps below assume that the firebird.conf in the Firebird installation has setting AuthServer = Srp (or at least that setting AuthServer contains Srp) and setting UserManager = Srp (or at least that Srp is the first entry for UserManager).
Option 1: reset a password
Works on Firebird 2.5 and higher
Connect to a database with SYSDBA (or another user with admin role on the security database), and use
ALTER USER <username> SET PASSWORD '<new password>';
This is probably not an option in your case though.
Option 1a: reset with embedded connection (passwordless)
Works on Linux for Firebird 2.5 or higher, on Windows requires Firebird 3.0 or higher.
Stop Firebird server, and use ISQL to connect to the database in embedded mode (which doesn't require a password):
isql -user sysdba <database>
With a default Firebird 3 installation, you can use employee for <database>, which will use the employee example database.
Alter the password as described above. Alternatively, try replacing sysdba with the actual username in the isql commandline.
Start Firebird server again.
Option 2: use gsec to change the password
Works on Linux for all version, on Windows this only works for Firebird 3.0 and higher.
Be aware that gsec is deprecated since Firebird 3 and may be removed from future Firebird versions.
Stop the Firebird server, open the command line, and in the Firebird installation folder do:
gsec -user sysdba
and on the gsec prompt
modify <username> -pw <new password>
or if the user doesn't exist yet:
add <username> -pw <new password>
Start Firebird server again.
Option 3: replace security database
Most of these steps also apply if you are using a new Firebird install; just skip the replacing of the security database.
Stop Firebird server and make a copy of your current security3.fdb as a backup.
Obtain a default security3.fdb for your platform (eg download a zipkit from the Firebird 3 download page) or use a security3.fdb with a known password, and replace your current security3.fdb with this default version. Don't start Firebird yet.
For earlier Firebird versions, look for your version on the download page.
The default password for sysdba is normally 'masterkey', but on Firebird 3 the default security3.fdb only contains this user for the legacy authentication mechanism, which is disabled in a default Firebird 3 installation.
To add a sysdba user, use an embedded connection to any database and create a sysdba account. On the command prompt from the Firebird installation folder, run:
isql -u sysdba <database>
Within ISQL execute:
create user sysdba password '<sysdba password>';
commit;
To add another user, connect using SYSDBA - similar to the previous step 2 - to any database and execute
create user <username> password '<new password>';
commit;
And exit isql (with quit;)
Then start Firebird server again, and you should be able to connect with this user and its password.
Most of these steps assume you already have a database to connect to, if you don't yet have one, then you'll need to create on first.
Start isql as user sysdba:
isql -u sysdba
And create a database
create database '<path-of-database>';
You can then use that database for the earlier steps.
However, it seems very trivial - How to get the current username of a database in DB2 software in IBM; But, trust me, when it comes to entering the database username and password while connecting DB2 with eclipse, you might have to wait for a time which is tediously long. Let's get straight to the point:-
This is how you get the username of a database in DB2.
open DB2 Command Line Processor .
Connect to your database:-
db2 => connect to <database_name>
Enter this query in db2 clp:-
db2 => SELECT CURRENT USER FROM SYSIBM.SYSDUMMY1
You'll get the current user name of the current database that you have accessed.
Now, the main problem is :- How to get / change the password if one has forgotten the password. And, What is the difference between database password and the one that i entered while installing DB2 ?
DB2 does not have its own set of IDs and passwords; it relies on the operating system to perform authentication. So your ID and password are what you used to log in to Windows (or Linux, AIX, etc); and you change your password as you do normally on each platform.
The password you entered during installation is for a different ID - DB2 created a new user on your local machine. On Windows the ID is called db2admin by default.
db2 "CONNECT TO <database> USER <userid> USING <password> NEW <new_password> CONFIRM <new_password>"
http://www-01.ibm.com/support/docview.wss?uid=swg21984232
I'm getting ORA-28000: account is locked error during oracle export utility. Issuing the below command:
expdp user/password tables=MY_TABLE directory=TABLE_EXPORT dumpfile=myexport.dmp CONTENT=DATA_ONLY COMPRESSION=ALL
I changed our database user account password and oracle export utility is not working ever since this password change. It locks the user account every time we try to run it.
As all my other jobs are working good with the same username and password, it has nothing to do with wrong username and password in expdp command.
It looks like some configuration or password syncs are required in some database files. Has anyone got any idea of solution to this weird situation?
Does the new password have special characters that could cause the shell script to behave differently?
May be helpful to know the account_status:
select username,account_status from dba_users;
This would tell us if the account is getting locked due to too many failed logins or is someone running "alter user account lock".
It happens due to multiple test connection or login attempts done with wrong parameters (aka user-name or password combinations).
Failure -Test failed: ORA-28000: the account is locked
Now, how to unlock that particular user in Oracle.
A privileged user (system, sysdba, or database administrator) must logon to the standby and unlock the account there.
ALTER USER locked_user_name ACCOUNT UNLOCK;
COMMIT;
This is the continue topic with this topic:
Oracle 10g: Error when creating database manually by scripts
Basically, I had created an Oracle database named "testdb" using only batch scripts and SQL scripts.
After successfully creating a database using script, I create a script to create user for client connect to the database.
CreateUser.bat
sqlplus sys/test as sysdba #D:\Script\CreateUser.sql
CreateUser.sql
shutdown immediate;
startup;
CREATE USER usr1 IDENTIFIED BY usr1
DEFAULT TABLESPACE users
QUOTA UNLIMITED ON users;
GRANT CREATE SESSION, GRANT ANY privilege TO usr1;
exit;
Everything run ok, with no error.
Then I try to test by connecting to SQLPlus on cmd:
sqlplus usr1/usr1#testdb
This retrun the error:
ORA-12154: TNS:could not resolve the connect identifier specified
I wonder what I did wrong.
The same happen for the database I created via DBCA.
The error is because you don't seem to have an entry for testdb in your tnsnames.ora file. You could add one, manually or with the configuration tools netca etc); or you could bypass that with the 'easy connect' syntax:
sqlplus username/password#//hostname:port/service_name
If this is on your local machine, the default port and the service name matches the SID, that could be simolified a bit to:
sqlplus usr1/usr1#//localhost/testdb
You can verify the service name in v$parameters, or with lsnrctl services.
You can read more about connections and naming methods.
If your are connecting to a database on the same machine as the client, and you are using the same ORACLE_HOME, you don't need to use TNS/SQL*Net at all. With ORACLE_SID set to the right value, just doing this will connect locally:
sqlplus usr1/usr1
you can sqlplus usr1/usr1#testdb when you create connect string. It means that you need to entry in tnsnames.ora file
I am using C:\Bugzilla>checksetup.pl and it shows me this error message...plz tell me how i connect to mysql with bugzilla....
There was an error connecting to MySQL:
Access denied for user 'bugs'#'localhost' (using password: NO)
This might have several reasons:
MySQL is not running.
MySQL is running, but there is a problem either in the
server configuration or the database access rights. Read the Bugzilla
Guide in the doc directory. The section about database configuration
should help.
Your password for the 'bugs' user, specified in $db_pass, is
incorrect, in './localconfig'.
There is a subtle problem with Perl, DBI, or MySQL. Make
sure all settings in './localconfig' are correct. If all else fails, set
'$db_check' to 0.
You need to grant access to the user bugs from localhost to this database. Try the following, replacing the relevant parameters
GRANT ALL PRIVILEGES ON DATABASENAME.* To 'user'#'localhost' IDENTIFIED BY 'password';
More information about GRANT