There are a couple of errors that you can get on database connection that simply mean you typed something wrong, but I figure there are people who will search on these errors, so I thought I would share. If you do not already have a database connection, you can get:
db2 conenct to SAMPLE 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
If you already have a connection to some other database, you might get:
db2 conenct to SAMPLE DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0104N An unexpected token "to" was found following "conenct ". Expected tokens may include: "JOIN". SQLSTATE=42601
In both of the cases above, the error was simply because I misspelled “connect”. Sometimes my fingers type faster than my brain. Simply correcting my syntax leads to a successful connection:
db2 connect to SAMPLE Database Connection Information Database server = DB2/AIX64 10.5.3 SQL authorization ID = DB2INST1 Local database alias = SAMPLE
[…] Quick Tip: Simple Errors on Database Connection […]
Just wanted to say that I’ve always found error checking and messages lacking in DB2. The error in either of the above illustrates the point. Instead of making it very clear that the ‘conenct’ portion is an unrecognized parameter to the ‘db2’ parent, it gives vague and misleading info in two different ways, depending on whether you’re already connected to some other DB. It would be easy for the opts logic portion of the compiled ‘db2’ command code to have a unicode message token that can state, in all cases of an unrecognized switch/param at any level of the command, something like:
“” is not recognized
And that can be placed at the end of the SQL0104N message. As it is, it doesn’t expressly state that ‘conenct’ is the unrecognized portion. This is okay for simple examples since it’s very easy to spot our mistakes; it’s vexing when you’re 4 levels deep in a SQL statement and it’s still giving the opaque “…An unexpected token ‘to’ was found following…” statement.
I know this is neither here nor there, but wanted to vent on this topic because I truly believe in doing good error checking AND good STDERR messages and this is one area DB2 falls short in. :-/
While I agree to some extent, I also think that, from what I’ve seen, Oracle is worse. I’ve been meaning to write a blog entry on some error checking tips.
Oh man, you couldn’t be more correct there. I’m working a good deal with Oracle on my present job and I’m very frustrated with the error message content. Trying to debug SQL in Oracle is rough and don’t even get me started with tracing enablement. I know some it my vexation is due to my relative lack of expertise with Oracle, so I make allowance for that. Still doesn’t save me any hair. 😉
The db2 “get connection state” command can aid in determining whether there is an existent database connection or not
Right – see this blog entry for more details: https://datageek.blog/2014/09/18/db2-quick-tip-checking-connection-state/