db2 => db2level
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL1024N A database connection does not exist. SQLSTATE=08003
what's wrong here?
db2level is an OS command, not a DB2 CLP command.
$ which db2level
/home/db2inst1/sqllib/bin/db2level
$ which db2
/home/db2inst1/sqllib/bin/db2
Related
Do PostgreSQL CLI commands on Windows work?
I'm trying basic command like --version or -V for PostgreSQL version info, but I can't get any result. I've tried multiple permutations, including:
--version w/ or w/o semicolon
\--version w/ or w/o semicolon
psql --version w/ or w/o semicolon
\psql --version w/ or w/o semicolon
I made sure that the PostgreSQL service is running.
Some commands work, for example \l.
If \l works, then you have already started psql.exe and thus you can only run SQL commands (that need to be terminated with ;) or meta commands that start with \
However there is no meta command to display the version of psql.exe, you can do that only from the Windows command line (cmd.exe)
c:\>psql --version
psql (PostgreSQL) 15.0
c:\>
But that only gives you the version of psql.exe, not the version of the Postgres server. If you want to find out the server version run the SQL command inside of psql:
c:\>psql postgres postgres
psql (15.0)
Type "help" for help.
postgres=# select version();
version
------------------------------------------------------------
PostgreSQL 15.0, compiled by Visual C++ build 1914, 64-bit
(1 row)
postgres=#
I use the following command to execute SQLs in a file by db2 command line processor (CLP) in Linux:
db2 -f script.sql
The encoding for script.sql is Windows-1252 (CP1252). When I run the command on server A, db2 reads and executes the file successfully but when I run the command on server B, db2 fails to read the file because it cannot recognize the French character encoded in Windows-1252.
The LANG environment variables on both servers are the same (en_GB). The versions of db2 CLP on both servers are the same and the operating systems are the same.
You may set the corresponding environment variable in your session.
export DB2CODEPAGE=1252
—- just in case if you ran db2 commands previously
—- in this session
db2 terminate
—- if there is no connect command in the script
db2 connect to mydb
db2 -f script.sql
—- if you need other Db2 commands
—- with your default code page in this session
db2 connect reset
db2 terminate
unset DB2CODEPAGE
Ran the following command based on the recommendation in a document:
db2set -g DB2SYSTEM=%computername%
db2extsec -u %computername%\db2users -a %computername%\db2admns
After that DB2 CLP is not opening. I just see a windows command prompt window. How can I fix it?
I'm executing the below query
mysql --xml -e 'SELECT * FROM testdb.nodes1' > file.xml
.
but it return always same error as mentioned below.
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'mysql --xml -e 'SELECT * FROM testdb.nodes1' >
file.xml' at line 1
kindly answer me..
I guess that you run this query in mysql console or in mysql-workbench. This is wrong way.
This query is for run in command line: bash or similar in Linux and cmd in Windows.
I am trying to restore the postgres sql data from a file . I am trying to do so but it is not importing .
Here is the command which i am using:
postgres-# psql -hlocalhost -p5432 -u postgres -d test -f C:/wamp/www/test/database_backups/backup004.sql
Please help me what I am doing wrong .
I am using windows and the above command does not throws any error but it does not import data.
Regards
Surjan
The only immediate thing I can see there is the capitilsation of -u for username (should be -U).
Correction: You're typing the command line into the psql shell.
You should exit to the CMD.EXE shell, and try the command there. With the correct capitalisation of -U, by the way.
OR, use this to replay the script into that psql shell:
\i C:/wamp/www/test/database_backups/backup004.sql
The forward slashes don't cause a problem on my Windows machine.