Re: Verify character encoding of database

Re: Verify character encoding of database

 

  

Thanks Sathya,

this is a great idea!
Since I do know, how the tables are created, I know that my VARCHAR
columns are defined without any codepage references. Therefore, those
columns refer to the system default codepage.

I was able to successfully distinguish between a database that has been
created with UTF-8 encoding support and one that was not.

Thanks so much,

Johannes





Sathya wrote:
> **A LazyDBA.com subscriber has responded to your lazydba.com post**
> **LazyDBA.com mail shield has forwarded you this email,
> **and removed any attachments, and kept your email address secret
> **from this person, and any viruses/trojans.
> **If you reply to this email, the person will see your email address as normal
> **Anything below this line is the original email text
>
>
>
>
>
>
> Hi,
>
> I am jumping in the middle of the discussion. I presume you are looking
> for codepage.
> which you can get it from syscat.columns and check it for 1028 which will
> be unicode.
>
> Let me know if this has helped.
>
> bye
>
>
>
>
> "SlowJoe " <db2udbdba-ezmlmshield-x21780268.[Email address protected] on
> 10/25/2004 09:58:43 AM
>
> To: "LazyDBA Discussion" <[Email address protected]
> cc:
>
> Subject: Re: Verify character encoding of database
>
>
> Hi Gary,
>
> this is the output of "db2level":
> ------------------------------------------------------------------------
> DB21085I Instance "DB2" uses "32" bits and DB2 code release "SQL08010"
> with
> level identifier "01010106".
> Informational tokens are "DB2 v8.1.0.36", "s021023", "", and FixPak "0".
> ------------------------------------------------------------------------
>
> DB2 V8.1 without any fixpack. Actually, I probably should apply fixpack
> 6a. I will do so now, if this will solve the problem. According to your
> mail it won't.
>
> However, I changed my code to that:
> ----8<-----------------------------------
> stmt = connection.prepareStatement("get db cfg for testdb");
> if (stmt.execute())
> {
> result = stmt.getResultSet();
> System.out.println(result.getString(1));
>
> while (result.next())
> {
> System.out.println(result.getString(1));
> }
> }
> else
> {
> System.out.println("Update count: " + stmt.getUpdateCount());
> }
> ----8<-----------------------------------
>
> The exception I get now is:
> ----------------------------------------------------
> COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0104N An
> unexpected token "get db" was found following "BEGIN-OF-STATEMENT".
> Expected tokens may include: "<drop_transf>". SQLSTATE=42601
>
> at
> COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown
> Source)
> at
> COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throw_SQLException(Unknown
> Source)
> at COM.ibm.db2.jdbc.app.SQLExceptionGenerator.check_return_code(Unknown
> Source)
> at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2(Unknown Source)
> at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute(Unknown Source)
> at
> com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkCharacterEncodingForDB2Multiplatform(DatabaseInsight.java:392)
>
> at
> com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkCharacterEncoding(DatabaseInsight.java:371)
>
> at
> com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkAndLog(DatabaseInsight.java:560)
>
> at
> com.ibm.wps.datastore.dbinsight.DatabaseInsight.main(DatabaseInsight.java:647)
>
> ----------------------------------------------------
>
> DB2 does not understand its own commands. My application connects to the
> DB2 server via DB2 Connect using the type 2 JDBC driver. The command
> line processor has no problems... If I would use the type 4 JDBC driver
> (JCC), I could understand that it does not work.
>
> Regards,
>
> Johannes
>
>
>
> Gary Hempstead wrote:
>
>>What version of DB2 you using?
>>
>>Found this:
>>
>>"To comply with the J2EE 1.3 standard, the DB2 JDBC driver, as of FixPak
>>5, no longer allows the use of a non-query statement with executeQuery,
>>nor a query statement with executeUpdate. Attempting to do so will
>>result in one of the following exceptions:
>>
>>CLI0637E QUERY cannot be found,
>>CLI0637E UPDATE cannot be found.
>>
>>If the type of statement is unknown, use execute()."
>>
>>-----Original Message-----
>>From: SlowJoe
>>[mailto:db2udbdba-ezmlmshield-x10080440.[Email address protected]
>>Sent: 25 October 2004 13:39
>>To: LazyDBA Discussion
>>Subject: Re: Verify character encoding of database
>>
>>Hi Gary,
>>
>>thanks for your suggestion.
>>I knew this command. Unfortunately, it does not help me in my case,
>>because I need to access the configuration information from within a
>>Java application.
>>This statement is not recognized as a valid SQL statement by the CLI.
>>This is a snippet of my code:
>>--8<--------------------------------------
>>stmt = connection.prepareStatement();
>>result = stmt.executeQuery();
>>
>>while (result.next())
>>{
>> System.out.println(result.getString(1));
>>}
>>--8<--------------------------------------
>>
>>And this is the exception I receive in return:
>>
>>------------------------------------------
>>COM.ibm.db2.jdbc.DB2Exception: [IBM][JDBC Driver] CLI0637E QUERY cannot
>>
>>be found.
>> at
>>COM.ibm.db2.jdbc.app.SQLExceptionGenerator.throwInvalidQueryError(Unknow
>>n
>>Source)
>> at
>>COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeQuery(Unknown Source)
>> at
>>com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkCharacterEncodingFo
>>rDB2Multiplatform(DatabaseInsight.java:392)
>> at
>>com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkCharacterEncoding(D
>>atabaseInsight.java:371)
>> at
>>com.ibm.wps.datastore.dbinsight.DatabaseInsight.checkAndLog(DatabaseInsi
>>ght.java:552)
>> at
>>com.ibm.wps.datastore.dbinsight.DatabaseInsight.main(DatabaseInsight.jav
>>a:639)
>>------------------------------------------
>>
>>What I need is a table or catalog view that gives me the character
>>encoding information.
>>Any idea?
>>
>>Regards,
>>
>>Johannes
>>
>>
>>
>>
>>
>>Gary Hempstead wrote:
>>
>>
>>>**A LazyDBA.com subscriber has responded to your lazydba.com post**
>>>**LazyDBA.com mail shield has forwarded you this email,
>>>**and removed any attachments, and kept your email address secret
>>>**from this person, and any viruses/trojans.
>>>**If you reply to this email, the person will see your email address
>>
>>as normal
>>
>>
>>>**Anything below this line is the original email text
>>>
>>>
>>>'get db cfg for database'
>>>
>>>Then look at the codepage/codeset.
>>>
>>>Rgds.
>>>
>>>-----Original Message-----
>>>From: SlowJoe
>>>[mailto:db2udbdba-ezmlmshield-x5362632.[Email address protected]
>>>Sent: 25 October 2004 11:02
>>>To: LazyDBA Discussion
>>>Subject: Verify character encoding of database
>>>
>>>Hi there,
>>>
>>>I need to connect to a DB2 database, which is required to be UNICODE
>>>enabled. Usually, it is created like this:
>>>
>>>db2 CREATE DATABASE testdb USING CODESET UTF-8 TERRITORY us
>>>
>>>Unfortunately, it is not me, who creates the database. I have to rely
>>
>>on
>>
>>
>>>the database admins to create it correctly.
>>>
>>>Now, I would like to verify the database settings. Is there another
>>
>>way
>>
>>
>>>than putting UNICODE encoded strings into a test table and query them
>>>afterwards to see, whether the strings are still the same?
>>>
>>>I looked through the SQL Reference Appendix D, where the catalog views
>>
>>
>>>are described... I did not find any related view.
>>>
>>>JDBC database metadata does not give me any evidence either.
>>>
>>>If you can give me an advice, I would greatly appreciate it.
>>>
>>>Thanks,
>>>
>>>Johannes
>>>
>>>
>>>---------------------------------------------------------------------
>>>PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
>>>website: http://www.LazyDBA.com
>>>To unsubscribe: http://www.lazydba.com/unsubscribe.html
>>>
>>>
>>>
>>>
>>>
>>
>>************************************************************************
>>
>>
>>>If you have received this e-mail in error, please delete it and notify
>>
>>the sender as soon as possible. The contents of this e-mail may be
>>confidential and the unauthorized use, copying, or dissemination of it
>>and any attachments to it, is prohibited.
>>
>>
>>>Internet communications are not secure and Hyperion does not,
>>
>>therefore, accept legal responsibility for the contents of this message
>>nor for any damage caused by viruses. The views expressed here do not
>>necessarily represent those of Hyperion.
>>
>>
>>>For more information about Hyperion, please visit our Web site at
>>
>>www.hyperion.com
>>
>>
>>>
>>
>>---------------------------------------------------------------------
>>PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
>>website: http://www.LazyDBA.com
>>To unsubscribe: http://www.lazydba.com/unsubscribe.html
>>
>>
>>
>>
>>************************************************************************
>>
>>If you have received this e-mail in error, please delete it and notify
>
> the sender as soon as possible. The contents of this e-mail may be
> confidential and the unauthorized use, copying, or dissemination of it and
> any attachments to it, is prohibited.
>
>>Internet communications are not secure and Hyperion does not, therefore,
>
> accept legal responsibility for the contents of this message nor for any
> damage caused by viruses. The views expressed here do not necessarily
> represent those of Hyperion.
>
>>For more information about Hyperion, please visit our Web site at
>
> www.hyperion.com
>
>>
>>---------------------------------------------------------------------
>>PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
>>website: http://www.LazyDBA.com
>>To unsubscribe: http://www.lazydba.com/unsubscribe.html
>>
>>
>
>
>
> ---------------------------------------------------------------------
> PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
> website: http://www.LazyDBA.com
> To unsubscribe: http://www.lazydba.com/unsubscribe.html
>
>
>
>
>
>
>

DB2 & UDB email list listserv db2-l LazyDBA home page