フォーラムへの返信
-
投稿
-
kairin さんこんにちは。
version 2.14.0 release candidate 2で高DPI環境下のレイアウト崩れを対処をもう少しやってみたいと思います。どうも、MDI子ウィンドウのスケーリング処理がうまく動いていないようでした。あと、ERエディタでエンティティのプロパティウィンドウがうまく動いていないようでしたので修正します。荒木さんこんにちは。
SJISのOracleデータベースを早急には用意できなかったのですが、エラーとしては、
「ORA-12899: 列”TABLE_SCHEMA”.”TABLE_NAME”.”COLUMN_NAME”の値が大きすぎます(実際: NN、最大: MM)」
のような感じでしょうか？。
半角500文字というのは1文字2バイトにも見えますが、全角 334文字というのはちょっと不思議ですね。1文字3文字にしても、1文字余計に入る気がしますし、半角の1文字2バイトとも整合性が取れません。あと、長さセマンティクスはバイト・セマンティクス(varchar2(1000 byte))ということでよろしいでしょうか？。
ちょっと不思議ですね。はけんさんこんにちは。
リレーションシップの線は右クリックして、「線の描き方」のところから線の形を選ぶことができます。縦に並んだエンティティで、横から線を出したいとすると、「(⊐) 型」あるいは「(⊏) 型」を選ぶとよいと思います。おっちちさんこんにちは。
不具合情報ありがとうございます。
現象を確認したのですが、結合された列は「折り返して全体を表示」の処理（プロパティの値を設定）してもなぜかうまく動いてくれないようです。Excelは前からこういう動作だったかなという気もするのですが、Excel自身がそのような動作をする以上、修正するのは困難かもしれません。
以上よろしくお願いいたします。やまさんこんにちは。
AIとは MySQL の auto_increment のことでしょうか？。確かに値がないとエラーになってしまうので修正したいと思います。
ちなみに、MySQL の場合、0を指定して挿入すると、適切な値に変換されて挿入されます。かやはらさんこんにちは。
TIMESTAMP WITH TIME ZONEは、タイムゾーンの情報(+09とか)付きで日付時刻を保持するというより、タイムゾーンを適宜変換して扱ってくれる型です。
https://www.postgresql.jp/document/9.4/html/datatype-datetime.html によると、以下のような入出力の動作をします。
>timestamp with time zoneについて内部に格納されている値は常にUTCです（協定世界時、歴史
>的にグリニッジ標準時GMTとして知られています）。 時間帯が明示的に指定された入力値は、その
>時間帯に適したオフセットを使用してUTCに変換されます。 入力文字列に時間帯が指定されていな
>い場合は、システムのTimeZoneパラメータに示されている値が時間帯とみなされ、timezone時間
>帯用のオフセットを使用してUTCに変換されます。
>timestamp with time zone値が出力されると、この値はUTCから現行のtimezoneに変換され、そ
>の時間帯のローカル時間として表示されます。 他の時間帯での時間を表示するには、timezoneを
>変更するか、あるいはAT TIME ZONE構文（項9.9.3 を参照）を使用します。
つまり、クライアントで入力した日付時刻はタイムゾーンを考慮してUNIZ TIME（多分）などに変換されて格納され、別のクライアントからクエリーされたときはそのクライアントのタイムゾーンに合わせた形で日付時刻表現に変換されて表示されます。
例えば、タイムゾーンが UTC のクライアントで 2018/11/11 0:00:00 を挿入（又は更新） した場合、 日本(JST)のクライアントでクエリーすると 2018/11/11 9:00:00 として表示されます。
ちなみに、to_char(current_timestamp, ‘YYYY/MM/DD HH24:MI:SS TZ’) 等とすると、to_char()は当然サーバーで処理されることになるので、サーバーのタイムゾーンで文字列に変換されることになるようです。Shunさんこんにちは。
データがない場合もエラーにはならないはずなのですが…。データベースの種類などをお教えいただけますでしょうか？。
とりあえず、一括エクスポート中にエラーが起こった場合は、テーブル名が分かるようにしたいと思います。
みやさんこんにちは。
何かプリンタ絡みで何か環境による問題があるのではないかなという気もしますが、よくわかりません。
OSに深く食い込むようなドライバを含むわけでもないので A5:SQL Mk-2がOSの機能まで巻き込んで不具合を起すというのもなかなか不可解に思います。
通常使うプリンタのプリンタドライバを再インストールするとか、通常使うプリンタを別のものに変更するなどすると何か変化はないでしょうか？。
あとは、C:\program files 配下はディレクトリのリダイレクトなども発生してよくわからないので、別のフォルダに配置してみるとよいかもしれません。（あまり関係ない気もします）
過去に Windows 10では「通常使用するプリンタ」絡みの仕様変更（不具合？）もあったりしたのですが、Windows 7だとこれも関係ないような気がしますし。
おのがわっちさんこんにちは。
とりあえず今のところ、こちらでは再現できていません。Azure環境は試せていないのですが、おそらく関係はないのではと考えています。
ただ、先頭しか実行されないというのはどのような状況でしょうか？。なにかエラーやメッセージ類は表示されたりするのでしょうか？。あと、範囲選択して実行すると、動作モードにかかわらず、そこだけ実行になるのですが、関係ありませんでしょうか？。
いぬぽんさんこんにちは。
はい、こちらでも再現しました。やはり、画面更新タイミングの問題で、ひとつ前に表示していたタブの処理時間を表示してしまっているようです。次のベータ版で修正したいと思いますので少々お待ちください。
井上さんこんにちは。
はい、今のところ、「テーマカラー」の機能ではいわゆる「ダークテーマ」は再現できません。
「テーマ」の機能で、例えば「Carbon」等を選ぶと、近いものになるかと思いますが、テーマ機能は多少「重く」なり、altキーの動作などが微妙に変わるのでこれはこれで検証してから使ったほうが良いかと思います。
ytさんこんにちは。
A5:SQL Mk-2でPostgreSQLに接続するとき、使用しているライブラリの制限（仕様？）でtext型に空文字列を設定できず、NULLとして解釈するようです。どうも内部的にCLOBとして扱っていることに何か関係がありそうです。
とりあえずの解決策としてはオプションダイアログで「PostgreSQL」タブの「TEXT型をラージオブジェクト(CLOB)型ではなく、文字列型として扱う。」をチェックすると、空文字列を設定できますが、8192バイトまでしか扱えなくなるのでデータによっては注意が必要です。
しなもんさんこんにちは。
select句にあるコメントは行の後ろにあるとみなして整形してしまっていました。
また、コメントを行末に持ってくる前提で、必要に応じてカンマとコメントの位置を入れ替えるロジックが動作していました。以下のようなSQLをうまく成形するための機能です。
整形前
123selectAAA, -- コメント１BBB -- コメント２整形後（列の前にカンマが来るような設定で整形するとき「コメント１」とカンマの位置が入れ替わる）
123selectAAA -- コメント１, BBB -- コメント２列名の前にコメントがあることを想定していないため、この機能が原因でうまく成形できていなかったようです。
とりあえず、次のベータ版でそのあたりを制御できるようにオプションを付けたいと思います。
