フォーラムへの返信
-
投稿
-
Yassさん初めまして。
上述ページのSQLは、掲示板に投稿した時点で、シングルクォートが別の文字に置き換わってしまっているはずなので、戻して実行していただけると助かります。sys.objects からデータが取得できるとのこと、ありがとうございます。
snd さんこんにちは。
pgAdmin4 でどのような仕組みになっているのかはよくわからなかったのですが、タイムゾーン付きタイムスタンプ（≒UTCでのタイムスタンプ）としてデータを受け取った後、文字列形式に変換する動作はクライアント側(A5:SQL Mk-2側)で行っています。
この時、set session timezone to ‘Asia/Tokyo’; としてセッションのタイムゾーンを変更していたとしても、これは「サーバー側のセッションプロセス」なのでクライアント側(A5:SQL Mk-2側)は影響を受けません。
なので、A5:SQL Mk-2では set session timezone の設定にかかわらず、クライアントOSのタイムゾーン情報に従って文字列化するので、このような結果になったのではないかと考えられます。
都度、セッションのタイムゾーン情報を問い合わせてその情報に従って表示を行うというやり方もあるかとは思うのですが、そのために都度サーバーに問い合わせを行うのは少しやりすぎかなとも思えます。なお、SELECT 時にWHERE句の条件として文字列でタイムスタンプを指定したとき、おそらく想定と異なる結果を返す一因となるので、クライアントOSのタイムゾーンとサーバー側のセッションプロセスのタイムゾーンを異なる値に設定するのはお勧めしません。
ひろしさんこんにちは。
Oracle 7.2というのは相当古いバージョンですね。Oracle 8i 以降でOracle のサーバー・クライアント間の通信プロトコルが変更され、Net8 と呼ばれるプロトコルになりました。基本的に A5:SQL Mk-2で直接接続できるプロトコルも Net8 以降の対応となります。それ以前の Oracle Database については近年では接続テストすらできてはいないのですが、OCI経由での接続を試して問題があるようなら、OLE DBプロバイダまたはODBCドライバを経由して接続してみてください。
kamijo さんこんにちは。
現象を再現しようとしたのですが再現できませんでした。エラーの発生するA5:SQL Mk-2のバージョンとDB製品の名前とバージョン、再現にその他の操作等必要であれば、お教えいただければと思います。hide さんこんにちは。
調査したところ、遅くなる現象は再現できませんでしたが、v2.16 から EditorConfig 対応を行っているので、これが関係しているかもしれません。EditorConfig の設定ファイルを探す動作(ファイルのあるフォルダからルートフォルダに向かって定義ファイルがないか検索する)が影響しているかもしれません。
現状ではこの動作をOFFにするオプションは存在しないのですが、この動作が影響しているとしたら、”.editorconfig” ファイルを作成し、”root=true”の1行を記述してSQLと同じフォルダに配置すれば、設定ファイルを探す動作をしなくなるので速くなるかもしれません。jun1s さんこんにちは。
調査したところ、読み取り専用ユーザーでは、なぜか information_schema.constraint_column_usage システムカタログが正常に取得できないようでした。information_schema.constraint_column_usage 内で使われている、pg_has_role(name,text) 関数が正しく値を返さなくなることまでは確認しましたが、どの権限が不足しているかまではよくわかりませんでした。
ちなみに、最初にテーブルエディタを起動したときは背景赤にならず、インデックスタブを開いた後は背景赤になるのは、最初にテーブルエディタを開いたときに主キーが取得できないため、背景赤にならないが、インデックスタブを開いたタイミングで、「主キーが存在しないときにユニークインデックスを見つけるとそれを代替とする」処理が入っているためです。ちょっとこの処理（仕様）が妥当かは再考したいと思います。KFさんこんにちは。
ちょうど SSH接続ライブラリの Devart SecureBridge ライブラリで修正版が出ていましたので Version 2.18.0 release candidate 1 で対応しました。これで、RSAxxxx形式の鍵ファイルを使用しても接続できるかと思います。KFさんこんにちは。
AlmaLinux 9.1(OpenSSH 8.7) を仮想環境に用意していろいろ試してみました。
不具合の修正はできていないのですが、いくつか分かったことがあります。
まず鍵形式による接続可否は以下の通りでした。
・鍵形式がRSA2048, RSA4096, RSA8192 ではSSH接続に失敗
・鍵形式がEd25519の場合は接続可能
鍵形式がRSA2048, RSA4096, RSA8192のとき、sha1 ハッシュ形式が使えなくてエラーになるのではなく、sha256形式のハッシュで署名の検証に失敗しているように見えます。
以下ログより
debug3: mm_answer_keyverify: publickey RSA signature unverified: incorrect signature
debug1: auth_activate_options: setting new authentication options
debug3: mm_request_send: entering, type 25
Failed publickey for masakazu from 192.168.44.1 port 59880 ssh2: RSA SHA256:fQEfOjI52zktP6VnqMvCnhH3viUh+3Hd8b4/JYeVYgY
ところで、OpenSSH は 8.8 から sha1 がデフォルトで使えなくなったような情報を見かけましたが、AlmaLinux は OpenSSH 8.7 でも sha1 が使えなくなっているのですかね？
さしあたりの対処としては、Ed25519 鍵を使うと接続できるようです。この症状を修正できるかどうかわかりませんが、もう少し試してみることにします。Dark さんこんにちは。
強制エンコーディングは相当古いPostgreSQL (PostgreSQL 7.x くらい？)用のオプションですが、やはりまだ使われているところはあるのですね。
最近は、PostgreSQL 9.0 より前のバージョンでは動作確認できていません。ちょっと調査してみたいと思いますが、古い環境ですので難しいところもあるかもしれません。t_nakamura さんこんにちは。
現状では、保存すると、それ以上 Undo できない仕様です。これは、テキストエディタに使っているコンポーネント由来の制限です。
調査したところ、エディタコンポーネントのソースコードを少し書き換えると保存を超えてUndoできるようでしたが、メリット・デメリットありそうな気がします。また、十分に調査できておらず、不具合が発生してしまう可能性があるようにも思えます。
ちょっと現状では、保存を超えた Undo は実装しない方が無難かなと思うのですがいかがでしょうか？KF さんこんにちは。
A5:SQL Mk-2 に内蔵しているSSHライブラリ(Devart 社 SecureBridge)は、鍵交換アルゴリズムとして、curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 に対応しているはずなのですが、どうも diffie-hellman-group1-sha1 でしか接続してくれないようにも見えます。（ちょっとよくわかりませんでした。）
もう少し調査します。
なお、A5M2.exe と同じフォルダに A5M2.log という空ファイルを作成すると、SSH経由での接続時にSSHの接続情報の詳細情報を含むログが出力されるようになります。
