ホーム › フォーラム › A5:SQL Mk-2掲示板 › 【要望】コマンドでA5起動DB接続(Version 2.16.0 beta 4)
- このトピックには50件の返信、1人の参加者があり、最後にItoにより3年、 9ヶ月前に更新されました。
-
投稿者投稿
-
松原正和キーマスター
Itoさんんこんにちは。
不具合報告ありがとうございます。
> A5:SQL Mk-2 Version 2.17.0 正常表示 (UTF-8(Non BOM))
> A5:SQL Mk-2 Version 2.18.0 上記の文字化け現象(UTF-8(Non BOM))とありますが、正常動作は version 2.16.0 beta 17 で、文字化けするのは version 2.16.0 beta 18 ということでしょうか?。とするとUniDACのバージョンアップの影響かもしれません。
Oracleの文字コード分かれば教えていただけますでしょうか?。(JA16SJISTILDE,AL32UTF8等)
Itoゲスト松原様
お世話になります。Itoです。失礼しました、ご指摘の通り
正常動作は version 2.16.0 beta 17 で、文字化けするのは version 2.16.0 beta 18です。
Oracleの文字コードは
SELECT A.* FROM NLS_DATABASE_PARAMETERS A
WHERE PARAMETER IN (‘NLS_CHARACTERSET’, ‘NLS_NCHAR_CHARACTERSET’)
—————————————————————-
PARAMETER VALUE
—————————————————————-
NLS_CHARACTERSET JA16SJIS
NLS_NCHAR_CHARACTERSET AL16UTF16
—————————————————————-
データベースのキャラクタセットは JA16SJIS で、
各国語キャラクタセットは AL16UTF16です。
以上、宜しくお願い致します。Itoゲスト松原様
お世話になります。Itoです。
Ver 2.15.0 において以下の現象を確認しました。
■現象(0121-1)
SQL検索結果クエリ画面の全角文字の値をテキストエディタへ
コピー&ペーストすると検索値の後ろに半角スペースが余計に付与される現象です。※50バイトまでは正常ですが、51バイト目から+25バイト半角スペースが付与されます(”△”:全角スペース、”_” :半角スペース)
TADRS LENGTHB(A.ADRS) LENGTH(A.ADRS)
漢漢漢漢漢漢漢漢漢漢漢漢漢漢漢漢漢漢漢△△△△△△_________________________ 50 25松原正和キーマスターItoさんこんにちは。
一応再現したのですが、件の現象が発生するのは、”CHAR型”の項目ということでしょうか。おそらく、DB接続ライブラリの中で文字列長とバイト長を取り違えている感じですね。まだ、再現できただけで調査はそれ以上していないのですが、調査していきたいと思います。Itoゲスト松原様
お世話になります。Itoです。
現象が発生するのは、”CHAR型”の項目です。
お忙しいところ恐縮でございますが、
宜しくお願い致します。Itoゲスト(現象について補足)接続し直すと文字化けが消える場合もあります。
松原正和キーマスターItoさんこんにちは。
実は私も先週は再現していたものの、今週末チェックしたところ再現しなくなってしまいました。修正はもう少しかかりそうです。
Itoゲスト松原様
お世話になります。Itoです。
お時間掛かること了解しました。条件がそろったときに再現するのですね。
調査の役に立てばと思い、以下の再現パターンをお伝えします。
——————————————–
Aマスタを9行検索しました。
Aマスタの3列目の項目で属桁は
CHAR(38) NOT NULL の項目カラムです
漢字値の後ろ(39バイト目以降)に以下の文字列が表示されました。( select distinct
AME , case when A
null then A.PAC
OBJECT_NAME end
ase when A.PACKAGE_
then A.OBJECT_NAME
as SUB_OBJECT_NAME
POSITION = 0 th
e ‘PROCEDURE’ e
——————————————–
Bマスタの8列目の項目で属桁は
CHAR(38)の項目カラムでは
漢字値の後ろ(39バイト目以降)に以下の文字列が表示されました。PL/SQL: ORA-00942:
6550: 行1、列23:
——————————————–
Cマスタの8列目の項目属性は
CHAR(10) NOT NULL
漢字値の後ろには不要な文字は表示されません。
——————————————–
Dマスタの3列目の項目属性は
CHAR(38) NOT NULL
漢字値の後ろには不要な文字は表示されません。
——————————————–
※何か情報が必要であればおっしゃってください。Itoゲスト松原様
お世話になります。Itoです。
別件ですが、以下のメッセージが出ました。
—————————————————————————–
SQL : select a.xxxxxx_NO,a.xxxxxxD_NO,a.* from xxxxxxビュー a where Hxxx in (‘3′,’5’)
SQL : ORA-01013: ユーザーによって現行の操作の取消しが要求されました。
ORA-02063: 先行のエラー・メッセージを参照してくださいline(KSDB111)。
—————————————————————————–
※xxxxでマスキングしています。
※同じSQL文を他ツール(オブジェクトブラウザ)実行すると正常に検索結果表示されました。
※ORA-01013コードをwebで確認しましたところ
———————————————-
解決方法
データソースの Oracle ODBC ドライバー構成を確認します。 [クエリタイムアウトを有効にする] オプションをオフにします。
———————————————-
と解決方法の記載がありましたが、こちらで何らかの設定が必要でしょうか?
ODBCは使用していなくOrackeクライアントで接続しています。
もし対処方法がありましたら教えて頂けますでしょうか?
お忙しいところ恐縮です。申し訳ないです。Itoゲスト松原様
お世話になります。Itoです。
SQL : ORA-01013: ユーザーによって現行の操作の取消しが要求されました。
ですが解決しました。
ツールの[設定]-[オプション]-[SQLタグ]-
タイムアウト秒数=30秒 ⇒ 300秒に変更して実行しましたところ
検索OKとなりました。
以後、設定を確認してから問い合わせする様に注意致します。松原正和キーマスターItoさんこんにちは。
とりあえず、タイムアウトの件は解決してよかったです。あと、できれば新しい話題は新しいスレッドを立てていただけると助かります。(長くて追いにくくなってきていますので。)Itoゲスト新しいスレッド、了解です。
Itoゲスト松原様
お世話になります。Itoです。
長くなりましたので新スレッドで登録します。
検索カラムの桁を越えたカラムに
余計な値が表示される現象が多発しております。
以下は事例です。
——————
事例1
Aマスタを9行検索しました。
Aマスタの3列目の項目で属桁は
CHAR(38) NOT NULL の項目カラムです
漢字値の後ろ(39バイト目以降)に以下の文字列が表示されました。
以下は9行ぶんで39バイト目からの表示情報だけお伝えします。
—————–
( select distinct
AME , case when A
null then A.PAC
OBJECT_NAME end
ase when A.PACKAGE_
then A.OBJECT_NAME
as SUB_OBJECT_NAME
POSITION = 0 th
e ‘PROCEDURE’ e
——————
事例2
Bマスタの8列目の項目で属桁は
CHAR(38)の項目カラムでは
漢字値の後ろ(39バイト目以降)に以下の文字列が表示されました。PL/SQL: ORA-00942:
6550: 行1、列23:
——————
※何か情報が必要であればおっしゃってください。松原正和キーマスターItoさんこんにちは。
情報ありがとうございます。こちらではなかなか再現しません。引き続き調査したいと思います。Itoゲスト松原様
お忙しい中、引き続き宜しくお願いします。
一度は再現でき、それ以降は再現できないのですね?こちらでは問題の現象は常に出ている状況です。
感覚的には、1レコード全体長が長いテーブル
(トランザクション系)のレコードに含まれる全角値の
カラムにおいては現象が現れていなく、
全体レコードが短いテーブル(マスタ系)においては
必ず現象が起きています。
こちらの環境、確認してお伝えする必要な情報が
ありましたらおっしゃってください。印象としては、
メモリー内部の情報を拾って表示されている、
全角を2バイトと認識されず、1バイトと見て
余計に、SGAメモリーにキャッシュされている
データを抽出、引いてきているイメージではないでしょうか?カラムに余計に表示された値(sqlの断片)が
v$sql、v$sqlarea、v$sqltextに含まれているか
確認して見たら良いでしょうか?
アドバイス頂けたらあたりがつけやすく
原因究明に有益な情報を採取できると思います。
勘所を教えて下さい。 -
投稿者投稿