フォーラムへの返信
-
投稿
-
mrmrさん、侍さんこんにちは。
A5:SQL Mk-2 は他のソフトウェアと比較しても比較的変化に対して保守的であり、過去との互換性や古いデータベースへの対応を可能な限り行う方針で開発しています。
しかしながら、ソフトウェア開発に求められる要件も時代とともに変わります。A5:SQL Mk-2 も変化し続けなければなりません。
SQLエディタの色付きのコピー機能(HTML形式でのコピー)についてですが、Officeなどでも貼り付け時に形式を選択して貼り付けできることからカラー表示が不要な場合でも負担は少ないと考え導入しました。
また、現時点では実装されていないようですが、Excel についても、Shift+Ctrl+V でプレーンテキスト形式での貼り付けがサポートされる予定があるようです。
A5:SQL Mk-2 Version 2.18.0 release candidate 4 でShift+Ctrl+C で「プレーンテキスト形式でコピー」を実装します。ご確認いただければと思います。Yass さんこんにちは。
もしかしてですが、ODBCドライバかOLE DBプロバイダで接続していますか？
そうであれば「データベースの追加と削除」ダイアログから専用接続で「Microsoft SQL Server と SQL Server Compact」を選択して追加して試てみてください。
そうでない場合は、ちょっとよくわかりません…。A5M2.exe と同じフォルダに A5M2.log という空ファイルを作ると、ログを出力するようになり、A5:SQL Mk-2 が内部的に実行しているSQLを含めて出力されるようになります。ここで何かわかるかもしれません。CHAT さんこんにちは。
そうですね。最近はODBCドライバが提供されないようなDBも増えているので…。
とはいえ、A5:SQL Mk-2はJavaで書かれているわけではないので、当然そのままではJDBCドライバは呼び出せません。
A5:SQL Mk-2 と DB の間で、JDBC ドライバで接続できるプロキシサーバーみたいな機能を作りこめばできると思うのですが、なかなかそこまでは実装できません。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) 関数が正しく値を返さなくなることまでは確認しましたが、どの権限が不足しているかまではよくわかりませんでした。
ちなみに、最初にテーブルエディタを起動したときは背景赤にならず、インデックスタブを開いた後は背景赤になるのは、最初にテーブルエディタを開いたときに主キーが取得できないため、背景赤にならないが、インデックスタブを開いたタイミングで、「主キーが存在しないときにユニークインデックスを見つけるとそれを代替とする」処理が入っているためです。ちょっとこの処理（仕様）が妥当かは再考したいと思います。
