過去の桐井戸端ＢＢＳ　（桐ver.９）
26449 桐のデータを外部DBにバッチ処理のような方法で一括してエクスポートすることはできますか かも 2004/05/25-02:21
桐テーブルのデータを外部DB（Oracle or PowerGres）にバッチ処理（ボタンクリックのようなユーザーイベント）のような方法で
一括してエクスポートすることは可能でしょうか。
CSV形式ファイルへエクスポートが出来ることは確認できましたが、
その先の処理（外部DBをUPDATEする方法）が現在解らない状態です。
解決方法ありましたら、ご教示お願い致します。

26451 Re:外部DBへのエクスポートについて うにん 2004/05/25-11:47
記事番号26449へのコメント

>桐テーブルのデータを外部DB（Oracle or PowerGres）にバッチ処理（ボタン
>クリックのようなユーザーイベント）のような方法で一括してエクスポート
>することは可能でしょうか。

外部DBに主キーがあれば、桐側で更新できます。
ないと、めんどう。

26461 Re:外部DBへのエクスポートについて hidetake 2004/05/26-00:16
記事番号26451へのコメント
>桐テーブルのデータを外部DB（Oracle or PowerGres）にバッチ処理（ボタン
>クリックのようなユーザーイベント）のような方法で一括してエクスポート
>することは可能でしょうか。

どういうデータがあって何をされたいのかがよくわかりませんね？


>桐テーブルのデータを
>一括してエクスポート

だったら、単に「書き出し」で「外部DB」を選べば良いだけでしょうし


>CSV形式ファイルへエクスポートが出来ることは確認できましたが、その先の
>処理（外部DBをUPDATEする方法）が現在解らない状態です。

UPDATE となると、「外部DB」側と「桐」側で、どのようなデータ構成になっていて、
どういう関係でどのように UPDATE したいのか？

雰囲気的には、ただ「外部DB」からデータを取ってきて、それを桐でデータ更新するだけでなく、
桐の持っている何らかのデータで更新したいように思えます。

だとすると、桐側で「外部DB」のデータを更新できるように、
うにんさんの書かれているように外部DBに主キーがある必要がありますが
そうであれば、外部DB で必要なデータを取ってくるのと更新したい項目も表示させるようにして、
表示させた段階で、桐の持っているデータ(テーブル)と表引きで置換するか、
併合で置換させるとかで可能ではあります。


あるいは書いてあることを素直に読んで、書き出した CSVファイルのデータを元に
「外部DB」のデータを更新したいとなると、全く桐の話題では無くなってしまいそうです。


それから毎度書くけど、桐から「外部DB」のデータを更新される場合は、
外部DB側のデータが共有状態にあり、頻繁にデータのアップデイトが発生していると、
桐でデータを読み取ったあとで、もし「外部DB」側のデータが更新されていたらどうなるか、
そのあとで桐側からデータを更新したらどうなるかなど、
十分に気をつけないとデータの整合性がとれなくなるので十分に気をつけた方が良いです。


26462 Re:外部DBへのエクスポートについて hidetake 2004/05/26-00:29
記事番号26461へのコメント
>そうであれば、外部DB で必要なデータを取ってくるのと更新したい
>項目も表示させるようにして、表示させた段階で、桐の持っている
>データ(テーブル)と表引きで置換するか、併合で置換させるとかで
>可能ではあります。

う～む、外部DB の置換で #表引き関数を使うと相手のテーブルを
取り間違えるバグがあるようです。（桐9-2004）

上記テストのために [id] と [data] を言う全く項目を持つ「test.xvw」と
「test.tbl」の間で、「test.xvw」を開きデータを表示させた状態で [data] 項目で
#表引き([id],=,"test.tbl",[id],[data]) と置換を行うと、
test.xvw は自分自身だとエラーを発して置換ができませんねぇ～　(-_-;

test.tbl を work.tbl にリネームして
#表引き([id],=,"work.tbl",[id],[data]) とやると正しく置換され
ます。どうも、同じファイル名の .xvw と .tbl 間の「#表引き」では
ファイルの取り扱いがバグっているようです。　(;_;)

なお、このバグは外部DB の .xvw だけでなく、結合表の .viw でも一緒のようです。
26465 Re:外部DBへのエクスポートについて かも 2004/05/26-12:37
記事番号26451へのコメント

>外部DBに主キーがあれば、桐側で更新できます。
>ないと、めんどう。
>
うにん様
ありがとうございます。
色々と調査しておりますが、おっしゃるように大変めんどうな作業が待ち構えているように把握しています。
26466 Re:外部DBへのエクスポートについて かも 2004/05/26-12:42
記事番号26461へのコメント

hidetake様
ありがとうございます。

桐の外部BDでテーブル構造を同じにして、色々とテストを行っております。
ご助言頂いた様に整合性の問題などありましてCSVファイル書き出し後、
「外部DB」をバッチ処理で更新する方向で検討しております。
この方法での弊害もありまして、今後ご教示いただくこともあるかと思います。
宜しくお願い致します。
26468 Re:外部DBへのエクスポートについて hidetake 2004/05/26-13:23
記事番号26466へのコメント
>桐の外部BDでテーブル構造を同じにして、色々とテストを行っております。
>ご助言頂いた様に整合性の問題などありましてCSVファイル書き出し後、
>「外部DB」をバッチ処理で更新する方向で検討しております。

未だによくわかりませんが、これだと完全に桐とは関係ない話になってしまいますよね！？

わざわざ CSVに書き出して、そのデータを元にいろいろやるぐらいだったら？
　外部DBサーバ側にワークテーブルでも作っておいて
そのテーブルに「桐」からは「書き出し」の「外部DB」でデータの
書き出しだけやり、あとは外部DBサーバ側で、そのワークテーブルに対するトリガーで
INSERT イベントでも使い、そのデータやら外部DB側で持つデータとの関係で、
内部的にデータ操作をやられた方がいいのでは無いでしょうか？

もちろん、桐で「書き出し」の「外部DB」を行ったあとは、「桐」とは全く関係ない
「外部DB」（Oracle or PowerGres）自体の話になるし、
使う外部DB により方法やプログラムも異なってくる内容だと思いますが・・・
26473 Re:外部DBへのエクスポートについて うにん 2004/05/26-15:02
記事番号26468へのコメント
結構問題ありそうですね。

>わざわざ CSVに書き出して、そのデータを元にいろいろやるぐらい
>だったら？　外部DBサーバ側にワークテーブルでも作っておいて
>そのテーブルに「桐」からは「書き出し」の「外部DB」でデータの
>書き出しだけやり、あとは外部DBサーバ側で、そのワークテーブル
>に対するトリガーで

2004では追加書き出しできるようになったんでしょうか。。。
SP1では追加しても上書きされてしまうのでトリガーは無理そうです。
だめなのはPostgreSQLだけ？

26474 Re:外部DBへのエクスポートについて hidetake 2004/05/26-15:42
記事番号26473へのコメント
>2004では追加書き出しできるようになったんでしょうか。。。
>SP1では追加しても上書きされてしまうのでトリガーは無理そうです。
>だめなのはPostgreSQLだけ？

この辺は実に複雑というか？　「桐」の大文字・小文字の取り扱いや、
オブジェクトの " " で括るか括らないかの問題もあり、
何がなんだかわからない状態になるほど私自信も混乱しています。

おそらく PostgreSQL で追加で上書きされるのは ODBC ドライバで片岡さんのものを使った場合だと思われます。

PostgreSQL ODBC Driver 07.01.0006 日本語版（2001/07/13版） ODBCドライバ

http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/
http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/psqlodbc-jp-20010713-bin.zip

新しい、いのっち父さんの 7.03.0208 だと上書きには
ならないけど、桐がテーブル名の取り扱いで、" " で括る場所と括らない場所があり、
正しく処理していないので１度目の書き出しでは小文字でテーブルが外部DB に対し作られるけど、追加の際は " " なしで INSERT しようと
するので、外部DB 側では大文字のテーブル名として処理され、テーブルが無いとはねられ、
結局はデータの追加はできないと思います。

ＯＤＢＣドライバ・ダウンロードページ
http://www.geocities.jp/inocchichichi/psqlodbc/indexj.html
http://gborg.postgresql.org/project/psqlodbc/projdisplay.php


だから、PostgreSQL で(PowerGres でもか？)、先のようなトリガを使う場合は、
ワーク用のテーブルは毎回上書きで新規作成し(書き出しの外部DBで)、
トリガを発生させるテーブルは別途用意し、これは外部DB接続でデータ更新を
行いフラグ操作し、トリガを実行させることになるでしょうか？
あるいは VBS から操作したって構わない！


例的には前に出した感じでいけると思います。

桐のデータの一部をweb公開するためPostgreSQLとリンクさせたい
http://www.fuku3.com/~habata/kbbs/kakov8/21104.htm


# はっきり言って、「桐」の外部DB を使うぐらいなら他の
# ものが使えるのなら他を使った方が苦労は無いような気が
# します。(参照系だけでなく更新まで発生する場合) ヽ(;´o｀)丿


26475 Re:外部DBへのエクスポートについて hidetake 2004/05/26-16:06
記事番号26474へのコメント
>この辺は実に複雑というか？　「桐」の大文字・小文字の
>取り扱いや、オブジェクトの " " で括るか括らないかの
>問題もあり、何がなんだかわからない状態になるほど私
>自信も混乱しています。
>
>おそらく PostgreSQL で追加で上書きされるのは ODBC
>ドライバで片岡さんのものを使った場合だと思われます。

一部書き漏らした部分もありますが、私が「桐」の「外部DB」をさわりだしたのは
桐ver7.1 の頃だと思いますが、いくつかの外部DB で試してはおります。

その中で、桐の「書き出し」の「外部DB」では追加しても上書きされるというのが
頻発していたと思うので、何年間たつとともに「桐」の外部DB って、他の部分でもいろいろ問題はあるし、
作りも中途半端だからそんなものだろうと信じ込んで来た部分があります。

確実に再現できるのは、上記の PostgreSQL + 片岡さんのドライバであり、
他のAccess や SQL Server でも経験があるような気がします。
でも、昨年末、いろいろ調べた際は検証できませんでした。他の環境のバージョンも変わっていますしね！

この問題は桐のオブジェクトの扱いで、オブジェクト名を " " で括ったり括らなかったり、
あるいはオブジェクト名を直接に使わずに別名で使ったりしている部分もあり、
一筋縄ではいかない複雑な動きをするようです。ですので桐側はほとんど
変更は無いと思いますが、外部DB 側がオブジェクト名の大文字・小文字を区別するか？とか、
デフォルトでは大文字で処理されるのか？小文字で処理されるのか？も関わってくるかと思います。
なので、ドライバなどの細かいバージョンで影響される場合もあるかも知れません。


この辺は昨年秋に意を決して、ODBC のログを取ったり詳しく調べて K3 のサポートに報告したのですが、
報告しても一向に回答もこず、２ヶ月も３ヶ月もたって
ようやく中途半端な回答がきたこともあります。問題を指摘した部分も全部には
回答せず、仕方ないので何度も送り返してようやく返事が来たり・・・
こっちはログ取って細かい部分まで追いかけていたのですが、２～３ヶ月も回答が来ないので、
細かい内容は忘れたりで、K3 の回答が来たら、それを再確認するために再度ログを取り直してチェックしたり・・・
一挙に調べてくれて回答があれば、こっちの脳内もホットな状態でやりとりできるけど、
時間が空くと年取った私には記憶が薄れ、会話が成り立ちません！　(;_;)


桐って、もともと進歩が遅かったけど、昔はサポートだけはちゃんと対応してくれていたけど、最近はそれさえも・・・　(;_;)


まぁ～、そんなこんなで？桐の外部DB の場合はいろいろあります。
26476 Re:外部DBへのエクスポートについて hidetake 2004/05/26-16:27
記事番号26475へのコメント
桐と PostgreSQL の関係で書いておくと、いのっち父さんの最新の
ODBC ドライバ 7.03.0208 を使って、「書き出し」の「外部DB」で
追加処理もできるようにするには、書き出しの際のテーブル名に
大文字を使うことです。

最初に書き出し時に「上書き」なり「追加」でも最初からテーブル
名に大文字を使えば、２度目以降の書き出しで「追加」を指定しても
追加して書き出すことが可能です。

小文字のテーブル名を使ってしまうと、最初の CRETATE TABLE 時は
小文字のまま処理され新しいテーブルが作成され、
そして、そのまま INSERT でデータが作成(追加)されるけど、２度目に「追加」を指定すると、
テーブル名を桐は " " で括らないために大文字の
テーブルとして処理され、結局、そんなテーブルは存在しないと
エラーが発生しデータの追加はできません。

この部分は、Access や SQL Server に対しては桐は別名を使うので影響が出にくいと思います。


では、PostgreSQL + 桐 では大文字のテーブル名を使えばよいかというと、そうは簡単にはすみません。　(;_;)

外部DB でテーブルを開こうとする場合に、データを取ってくるくる部分に
「(すべて)」と指定して全部の項目を取ってこようとすると、
定義そのものは可能でも、データを開こうとするとエラーが発生し開くことはできません。
今度は、ここで「桐」は何故かテーブル名を勝手に小文字に変換して、
SQL文を投げかけるのです。定義画面では「大文字」で
テーブル名が表示されているにもかかわらずです。


これを回避するには、表示項目の指定で「(すべて)」は使わないで
１つ１つの項目を直にドロップして指定してあげる必要があります。


外部DB では、こんな問題がいっぱいあります。基本的な部分では
桐では「長さ 0 の文字列("")」と「未定義(#未定義)」を区別できないので、
これを区別する処理系では桐からはどうしようも無くなったりしますし・・・　困ったものです。　(;_;)
26478 Re:外部DBへのエクスポートについて hidetake 2004/05/26-18:51
記事番号26476へのコメント
>桐と PostgreSQL の関係で書いておくと、

先に書いたように 桐 + PostgreSQL の関係では、
桐のオブジェクトの扱いで、桐はオブジェクト名を " " で括るか括らないかの動作の統一性が無いがために、
オブジェクト名の大文字・小文字の問題の他にスペースを含んだオブジェクト名の問題も出てきます。

項目名の取り扱いまでは調べておりませんが、少なくともテーブル名ではスペースのあるものだと
パースエラーが発生し、正常に動作しない場合があります。

これは、何故か 桐 + PostgreSQL 関係で出やすいのですが、
Accessや SQL Server 相手には SELECT 1.* FROM "reikai test" ～ AS 1 と言うように別名を使うので、
この問題は出にくいのですが、PostgreSQL 相手だとテーブル名を直接投げかけるので
（SELECT reikai test.* FROM "reikai test" のように）おかしなSQL 文となってしまいます。

私が調べたのは、単純な単体のテーブル相手であり、もっと複雑な
結合や条件式をつけていくと、他の問題も出てくるのかも知れません。

ドライバや外部DB 側との関係もありますが、明らかに「桐」の動作でおかしいと思われる部分も多いので、
「桐」の「外部DB」を使う場合は、ターゲットの外部DB と使用するドライバとの関係も気をつけながら、
十分に桐の動作を見込んで使いこなさないといけないようです。（そこまでして使うか？と言う話も出てきそうですが！）


26543 Re:外部DBへのエクスポートについて うにん 2004/06/01-09:12
記事番号26478へのコメント
hidetakeさん

>項目名の取り扱いまでは調べておりませんが、少なくともテーブル名
>ではスペースのあるものだとパースエラーが発生し、正常に動作しな
>い場合があります。

さすがにそこまでは期待しませんが、

>これは、何故か 桐 + PostgreSQL 関係で出やすいのですが、Access
>や SQL Server 相手には SELECT 1.* FROM "reikai test" ～ AS 1
>と言うように別名を使うので、この問題は出にくいのですが、
>PostgreSQL 相手だとテーブル名を直接投げかけるので
>（SELECT reikai test.* FROM "reikai test" のように）おかしな
>SQL 文となってしまいます。

この辺は桐がわざわざ処理を変えてるとは考えにくいのですが。
ASを使ってるのはドライバの機能ではないですかね？
取得できるメタデータがおかしいのかなあ。。。

>ドライバや外部DB 側との関係もありますが、明らかに「桐」の動作
>でおかしいと思われる部分も多いので、「桐」の「外部DB」を使う
>場合は、ターゲットの外部DB と使用するドライバとの関係も気を
>つけながら、十分に桐の動作を見込んで使いこなさないといけない
>ようです。（そこまでして使うか？と言う話も出てきそうですが！）

少なくとも、MSのとOracleのでは使えてしかるべきでしょうが、
他の場合は期待しない方がよさそうですね...意気消沈

pgsqlのドライバを7.03.0208に交換して外部DB書き出しを試してみたら、
"create table "OOMOJI" ( "id" int4,"t" char()(11))\ 0"
parse errorになってしまいました。
SQLExecDirectのとこだから桐のSQL文生成部の問題なんでしょうかね T_T
しかし前のだと
"create table "NEW" ( "id" int4,"t" char(11))\ 0"
のようになるので、メタデータが「char()」と括弧つきで返るように
なってるだろうドライバ側の問題でもあるような？

前に「桐のODBCは異常に遅い」と言った覚えがあるのですが、
SQLのログがonになってたのでした。offにすればそこそこ使えました。
それにしてもACCESS相手だと無駄な「<SQL_ASYNC_ENABLE>」が大量に
記録されています。

26544 Re:外部DBへのエクスポートについて hidetake 2004/06/01-10:30
記事番号26543へのコメント
うにんさんどうも！

>この辺は桐がわざわざ処理を変えてるとは考えにくいのですが。
>ASを使ってるのはドライバの機能ではないですかね？
>取得できるメタデータがおかしいのかなあ。。。

この辺まではよくわかりませんが、別名を使えるかどうかの条件が
何かあり、桐はその PostgreSQL からの条件をうまく取得できないのか
期待した値でないのかわかりませんが、別名を使わないようです。
Access 相手や SQL Server 相手だと少なくとも別名を桐は使うようです。

で、ほとんど似たような使い方を同じパソコン＆同じドライバで
Access で行っても何も問題は無いのですよね！　でも、桐でやろうとすると
いろいろ問題が出てぶち当たることだらけです。　(;_;)

あと、この辺の「外部DB」周りの「桐」の動作を探るなら、
桐ver8の方はデバッグはやりやすいかも知れません。
KIRI8.INI の [Query] セクションに SQLOutput=1 を設定しておくと、
桐の内部的な SQL文と、それを ODBC に渡すときの SQL文までぐらいは確認できるようです。
あとは、ODBC のログ情報と PosgreSQL のドライバ自体のログ情報から中身を解析することになるかと思います。


>pgsqlのドライバを7.03.0208に交換して外部DB書き出しを試してみたら、
>"create table "OOMOJI" ( "id" int4,"t" char()(11))\ 0"
>parse errorになってしまいました。
>SQLExecDirectのとこだから桐のSQL文生成部の問題なんでしょうかね T_T
>しかし前のだと
>"create table "NEW" ( "id" int4,"t" char(11))\ 0"
>のようになるので、メタデータが「char()」と括弧つきで返るように
>なってるだろうドライバ側の問題でもあるような？

これって、何か出たことがあるかな？　あるような無いような？　(^^;
もちろん、ODBC 側の問題もあるにはあると思います。ただ、
上記の件と、オブジェクト名の大文字・小文字問題とは別ですね。


>"create table "OOMOJI" ( "id" int4,"t" char()(11))\ 0"

あっ！　思い出しました。このエラーはいのっちの父さんの最新ドライバを使うと出るのでした！　(^^;
私の現在使っているのは 2003/10/22 23:11:02 付けの 07.03.0200のものでした。　_o_

ftp://ftp.postgresql.org/pub/odbc/versions/dll/
ftp://ftp.postgresql.org/pub/odbc/versions/dll/psqlodbc-07_03_0200.zip

これだったと思います。

# いのっち父さんの書き込みを見ると、PostgreSQL 自信やドライバにも
# いろいろあるようだし、PostgreSQL の行く末もどうなるのか・・・　(^^;
# ただ、私の使うぐらいの範囲では Access では問題なくても「桐」では
# 困った問題がいろいろぶち当たるというのが困ったものです。　(;_;)


26545 Re:外部DBへのエクスポートについて hidetake 2004/06/01-10:30
記事番号26544へのコメント
あと、桐の外部DB のテーブル名での大文字・小文字の取り扱いの
問題についての kthree サポートからの報告をアップしておきます。
（2004/01/29 付けの回答より）

> ２．外部DB処理時のテーブル名大小文字区別について
>
> ご報告頂きました通り、現状の桐では、Case-Sensitiveな名前空間をもつ
> 外部DBに対する、テーブル名の扱いに問題があるようです。
> （一部のSQL文生成時に、テーブル名を大文字変換する等）
>
> 詳細は調査中ですが、この問題は非常に複雑で一部のODBCドライバでは、
> サポート機能の問い合わせに対して、
> 「Case-Sensitiveである」と応答するにも関わらず、大小文字を区別せずに
> 動作するものもあります。
> また、現在稼動しているシステムの動作互換性まで考慮した場合、
> 簡単には桐の動作を修正できないのが実情です。
> （常に二重引用符で括る等、安易な修正は危険であると考えられます）
>
> もちろん、桐の動作に問題があるのは事実であり、改善すべき問題で
> あると認識致しております。
>
> お客様には大変ご迷惑をおかけいたしますが、ご理解の上、運用による
> 回避（外部DBのテーブル名を大文字で統一する等）をお願い致します。
>
> なお、書き出し時の上書き動作につきましても、上記問題が根本的原因で
> あるとの方向で調査中ですが、いまだ断定できる状況にありません。
> 何らかの原因で、追加書き出しすべきテーブルが存在しないものとして、
> 上書き動作してしまうことがあるようです。
> もし、何らかの情報をお持ちでしたら、お知らせいただければ幸いです。


26546 Re:外部DBへのエクスポートについて hidetake 2004/06/01-10:39
記事番号26544へのコメント
>私の現在使っているのは 2003/10/22 23:11:02 付けの 07.03.0200
>のものでした。　_o_
>
>ftp://ftp.postgresql.org/pub/odbc/versions/dll/
>ftp://ftp.postgresql.org/pub/odbc/versions/dll/psqlodbc-07_03_0200.zip
>
>これだったと思います。
>

一応、PostgreSQL の正式版のドライバとしては 07.03.0200 が最新で
いのっち父さんのところにある 07.03.0208 は、まだ正式版とまでは
認証されていなかったのかな！　いのっち父さんもすでに開発メンバーからは
外れたかも知れません。いろいろな問題があるようです。

ちなみに
ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/psqlodbc-07_03_0209.zip
なって言うのも出てはいるようですね。


26547 Re:外部DBへのエクスポートについて hidetake 2004/06/01-10:55
記事番号26546へのコメント
>ちなみに
>ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/psqlodbc-07_03_0209.zip
>なって言うのも出てはいるようですね。

これも 07.03.0208 と一緒のようです。
桐からの外部DB書き出しではエラーが発生しました。

ただ、Access だとほとんど似たような構成のテーブル
もエクスポートで書き出しが問題なくできるのですよね・・・　(;_;)


桐で PostgreSQL を使う場合は、外部DB書き出しで
上書きされる問題を気にしなければ、片岡さんの
ドライバ、そうでなければ大文字・小文字の問題で
エラーが発生しやすいけど 07.03.0200 を使うこと
になるのですかね？


26548 Re:外部DBへのエクスポートについて hidetake 2004/06/01-11:14
記事番号26547へのコメント
>桐で PostgreSQL を使う場合は、外部DB書き出しで
>上書きされる問題を気にしなければ、片岡さんの
>ドライバ、そうでなければ大文字・小文字の問題で
>エラーが発生しやすいけど 07.03.0200 を使うこと
>になるのですかね？

あと、今まで ODBC ドライバを片岡さんのドライバを使っていて、
それを新しくする場合の注意点を１つだけ書いておきます。

PostgreSQL のデータベースの言語設定の問題ですが片岡さんの
ドライバを使っている場合は、言語設定でデフォルトの
ASCII でも日本語の項目名などをそんまま使えてしまうようです。
言語設定は無視して決めうちで日本語処理しているのかも知れません。

それに対し、それ以降の ODBC ドライバ (07.03.0200とか)を使う場合は、
データベース側の言語設定にも十分に気を遣う必要があります。
すなわち initdb や createdb で EUC-JP のように日本語を明示的に付加して、
日本語の設定でデータベースを作成したりテーブルを作成していないと
日本語のオブジェクト名が文字化けします。

すなわち、昔作った db で片岡さんのドライバを使っているうちは何気なく日本語も使えていても、
ODBC ドライバだけ変えてしまうと日本語が正常に使えなくなる場合があると言うことです。

この問題は pgAdminⅡ を使う場合に特に重大な問題となります。

以上、参考まで　(^^;
26552 Re:外部DBへのエクスポートについて うにん 2004/06/01-21:06
記事番号26545へのコメント
PostgreSQLはもともとデフォルトが小文字でSQL標準と違うという問題点があるので、
その辺のからみかもしれませんね。

Oracle（ないしMSのSQLServerとか）なら管理工学もテストを十分してる
でしょうから問題が少ないのではないかと期待されますが。。。

26553 Re:外部DBへのエクスポートについて hidetake 2004/06/02-06:27
記事番号26552へのコメント
>PostgreSQLはもともとデフォルトが小文字でSQL標準と違うという問題点が
>あるので、その辺のからみかもしれませんね。

そうですね！　デフォルトが大文字のデータベースなら問題はいくらか出にくいと思います。
「桐」はオブジェクト名(テーブル名)の取り扱いで、オブジェクト名を" " で囲むところ(場合)と
囲まないところ(場合)があるのと、書き出しの外部DB で２度目以降の「追加」の場合だけは、
何故かテーブル名を強制的に大文字に変換し、しかも、" " で括って処理しているところに問題があります。

Oracle の場合はオブジェクト名は大文字がデフォルトでしたっけ！？
それだと問題は出にくいと思います。
MS の Access や SQL Server の場合は、デフォルトで大文字・小文字の
区別をして、オブジェクト名(テーブル名)をわざわざ " " で括らなくとも、
記述されたとおりの文字列で新規作成はされるけど、１度できたものに対してのリクエストは
大文字・小文字が入れ混ざっていても同一視してくれるので(要はWindowsのファイルシステムと一緒か！)、
これまた問題が出にくいのかも知れません。

MySQL(特にUNIX上の) や InterBase(Firebird) はどうなのだろうか？


26554 Re:外部DBへのエクスポートについて hidetake 2004/06/02-06:52
記事番号26552へのコメント
>PostgreSQLはもともとデフォルトが小文字でSQL標準と違うという問題点が
>あるので、その辺のからみかもしれませんね。

ところで SQL標準ではデフォルトのオブジェクト名は大文字で
作成・使用されると言う規則はあるのですか？

" " で括らない場合は大文字・小文字で区別されないのが普通ではあると思いますが、
内部的なオブジェクト名のデフォルトが大文字であると言うのは見つけられませんでした。

SQL 文の書き方は、いろいろな場所での規則もあって、
統一的では無いけれど、SQL のキーワードについては大文字、オブジ
ェクト名に関しては小文字を使って書いてるところは(が)多いような気もします。

オブジェクト名の取り扱いで、それを " " で括ってしまえば、
データベースサーバ側で大文字・小文字を区別して処理する
ものがほとんどだと思いますが、桐は、" " で括るところと
括らないところがあるので問題が発生しているのだと思います。
" " で括らないなら全部括らない！(当然スペースを含むオブジェクトは取り扱えなくなる)　" " で括るのだったら
全部の大文字・小文字を意識して " " で括った処理をする！
それがごっちゃになっているのだと思います。
(１つのSQL文内でも)
26555 Re:外部DBへのエクスポートについて hidetake 2004/06/02-07:06
記事番号26554へのコメント
>>PostgreSQLはもともとデフォルトが小文字でSQL標準と違うという問題点が
>>あるので、その辺のからみかもしれませんね。

ちなみに、PostgreSQL でも「桐」が「書き出し」の「外部DB」の
追加で、勝手にテーブル名を大文字に強制変換して " " で括った処理をシナイ限り、
テーブル名に小文字を使う限り問題はでなくなるのでは無いかな？
（ODBCドライバの07.03.0200を使う限り）(大文字のテーブル名を使うと先に出した別の問題が出ます)

それと Oracle の場合でも、新規作成で小文字のテーブル名を指定したり、
あるいは既存のテーブルが小文字で作成されているもの対しては、
「桐」からの「書き出し」の「外部DB」では同じ問題が出るのでは無いでしょうか？

Oracle は手元にもないし、触ったこともないので詳しいことはわかりませんが！　(^^ゞ
26556 Re:外部DBへのエクスポートについて hidetake 2004/06/02-07:21
記事番号26555へのコメント
>「桐」が「書き出し」の「外部DB」の追加で、
>勝手にテーブル名を大文字に強制変換

ひょっとして、これは「追加」処理の際、追加だから既存の
テーブルが存在するかどうかの判定が必要になるのですが、
その判定の際に、テーブル名が同一のものがあるかどうかのチェックで、
大文字・小文字でテーブル名が食い違っていたら一緒かどうかの判定はできないし、
多くの外部DB の場合大文字・小文字を区別しても同時に大文字・小文字を区別したテーブルはもてないので、
すべて大文字に変換した上で比較を行い、既存のテーブルが存在したと判断した場合でも
最初に指定されたテーブル名や、外部DB から取得したテーブル名を使うことなく、
自分自身で比較のために大文字に変換したあとのデータを使ってしまっているのかな？

結局、桐の外部DB で一番無難に使えるのは MS の柔軟な
Access や SQL Server だけなのかも？知れません。

# でも、Access や SQL Server でも「追加」で新規作成
# されてしまった経験もあったような気もするのですよね？　(^^;
26558 Re:外部DBへのエクスポートについて うにん 2004/06/02-14:13
記事番号26554へのコメント

>>PostgreSQLはもともとデフォルトが小文字でSQL標準と違う

これはpgsqlのドキュメントにそう書いてあったのですが、

>ところで SQL標準ではデフォルトのオブジェクト名は大文字で
>作成・使用されると言う規則はあるのですか？

デフォルトと書いたのは変だったかもしれません。
""でくくらない場合、と言うことなんですが。（通じてたみたいですが）

>" " で括らない場合は大文字・小文字で区別されないのが普通
>ではあると思いますが、内部的なオブジェクト名のデフォルト
>が大文字であると言うのは見つけられませんでした。

規格書を見ると、「内部で大文字で保存する」ようなことは書いてなさそうですが、
「A="A"やa="A"であってa="a"ではない」ことを実現するには
「大文字で保存」するか、「""がついてたときはつけたまま保存する」ぐらいしか思いつきません。
なので多分大文字になるのではないかと。

規格書は英語なのでよく読めませんがここにあります。
ftp://ftp.postgresql.org/pub/doc/sql/

26559 Re:外部DBへのエクスポートについて hidetake 2004/06/02-15:05
記事番号26558へのコメント
>>>PostgreSQLはもともとデフォルトが小文字でSQL標準と違う
>これはpgsqlのドキュメントにそう書いてあったのですが、

ありました。これですか・・・

PostgreSQL 7.2.3 ユーザガイド
Chapter 1. SQLの構文
http://www.postgresql.jp/document/pg721doc/user/sql-syntax.html#FTN.AEN492

> PostgreSQL が引用符の付かない名前を小文字として解釈することは
> SQL 標準とは相容れないもので、SQL 標準では引用符の付かない名前
> は大文字に解釈されるべきだとされています。したがってSQL 標準に
> よれば、foo は "FOO" と同じであるべきで、"foo" ではないはずなの
> です。もし移植可能なアプリケーションを書きたいならば特定の名前
> は常に引用符で囲むか、あるいは全く囲まないのいずれかに統一する
> ことをお勧めします。

う～む！？　初めて知りました。
26563 Re:外部DBへのエクスポートについて うにん 2004/06/02-19:46
記事番号26559へのコメント

>> PostgreSQL が引用符の付かない名前を小文字として解釈することは
>> SQL 標準とは相容れないもので、SQL 標準では引用符の付かない名前
>> は大文字に解釈されるべきだとされています。したがってSQL 標準に
>> よれば、foo は "FOO" と同じであるべきで、"foo" ではないはずなの
>> です。もし移植可能なアプリケーションを書きたいならば特定の名前
>> は常に引用符で囲むか、あるいは全く囲まないのいずれかに統一する
>> ことをお勧めします。
>
>う～む！？　初めて知りました。

ありゃ。それは意外でした。

桐が、そういう事情をしらずに（というかODBC的に取得できなくて？）
引用符を使ったり使わなかったりすると、うまくいかないのが当然ですねT_T

26564 Re:外部DBへのエクスポートについて hidetake 2004/06/02-20:13
記事番号26563へのコメント
>>う～む！？　初めて知りました。
>ありゃ。それは意外でした。
>桐が、そういう事情をしらずに（というかODBC的に取得できなくて？）
>引用符を使ったり使わなかったりすると、うまくいかないのが当然ですねT_T

そうですか？　(^^ゞ

ただ、他の DB で探しても foo と書かれた場合、内部的には FOO として
処理されるとか、そう言う規格があるというのは見つけられませんでした。
もちろん、大文字でしか値を持てないという処理系はあるというのはあり
ましたが・・・

結局は、内部的に大文字で処理されようが小文字で処理されようが
> もし移植可能なアプリケーションを書きたいならば特定の名前
> は常に引用符で囲むか、あるいは全く囲まないのいずれかに統一する
> ことをお勧めします。
につきると思いますし、これって当たり前の事ですよね！？　(^^;

何回も書くけど、「桐」は、これができていないのと勝手に大文字に
変換する部分があって問題が出ているのです。


たぶんに Oracle 相手だと特殊な処理を行っていそうなのと、他の ODBC
相手だと、特に MS系の Access や SQL Server のように寛容なシステムだけで
テストばかり行っている(いたがために？)と、普通に大文字・小文字を区別する
サーバ相手だと問題が発生したのかも知れません。

「書き出し」の「外部DB」の「追加」処理は、他の DB ではトラブルは発生しないのかなぁ～
　MySQL でも UNIX 上のものだと影響が出そうな気がしますが？

あるいは SQL Server でも大文字・小文字の区別を厳格に行うように
セットアップしたものであれば影響が出るような気もしますが？

どうなのだろう？　(^^;
26579 Re:外部DBへのエクスポートについて うにん 2004/06/03-16:09
記事番号26543へのコメント

>>これは、何故か 桐 + PostgreSQL 関係で出やすいのですが、Access
>>や SQL Server 相手には SELECT 1.* FROM "reikai test" ～ AS 1
>>と言うように別名を使うので、この問題は出にくいのですが、
>>PostgreSQL 相手だとテーブル名を直接投げかけるので
>>（SELECT reikai test.* FROM "reikai test" のように）おかしな
>>SQL 文となってしまいます。
>
>この辺は桐がわざわざ処理を変えてるとは考えにくいのですが。
>ASを使ってるのはドライバの機能ではないですかね？
>取得できるメタデータがおかしいのかなあ。。。

psqlodbc-07.03.0200のinfo.cを見ると、SQL_COLUMN_ALIASが"N"に
なっちゃってるので、そのせいかもしれません。（問題になってるのは
COLUMNのALIASじゃないのでちょっと違うのですが、TABLEのALIASというのはないみたい）
他にSQL_EXPRESSIONS_IN_ORDERBYも最近のバージョンでは"Y"でいいはずなのに"N"になっています。

26580 Re:外部DBへのエクスポートについて hidetake 2004/06/03-18:40
記事番号26579へのコメント
>psqlodbc-07.03.0200のinfo.cを見ると、SQL_COLUMN_ALIASが"N"に
>なっちゃってるので、そのせいかもしれません。（問題になってるのは
>COLUMNのALIASじゃないのでちょっと違うのですが、TABLEのALIASと
>いうのはないみたい）
>他にSQL_EXPRESSIONS_IN_ORDERBYも最近のバージョンでは"Y"でいいはず
>なのに"N"になっています。

なるほど？　間違ってそう言う部分を見て処理が異なっているのかも知れませんね？

でも、別名は使っても使わなくても構わないわけで、どちらでも正しくSQL文を生成してくれたら良いのですけれど・・・

でも、PostgreSQL って 表の別名も 列の別名もどちらとも使用可能なのに、
どうして SQL_COLUMN_ALIAS が "N" になっているのですかね？
コメントにある /* ODBC 2.0 */ ってどういう意味なのでしょう？　(^^;


ちなみに、表の別名の場合は AS を省略する方がほとんどの場合で通る
SQL文になるのですかね？　それに対し列の別名の方は AS をつけないと
Access や PostgreSQL では通らないのかな？
何か ODBC 側でこれらの違いは吸収させる方法とかあるのですかね？
SQLExecDirect で投げかければどうしようも無いでしょうけど？



あと、ついでながら Access & SQL Server 相手への SQL文は・・・
===================================================
Access
---------------------------------------------------
SELECT 1.* FROM "reikai test" AS 1 /* +UNDEFZERO */
**** ODBC SQL Statement ****
SELECT A1.* FROM `reikai test` A1
===================================================
SQL Server
---------------------------------------------------
SELECT 1.* FROM dbo."reikai test" AS 1 /* +UNDEFZERO */
**** ODBC SQL Statement ****
SELECT A1.* FROM "dbo"."reikai test" A1
===================================================


# ここで続けるのも何でしょうからメールでもいただければ私の掲示板
# をお知らせ致します。興味でもあればどうぞ？　(^^;
26598 Re:外部DBへのエクスポートについて hidetake 2004/06/04-13:54
記事番号26559へのコメント
>>>>PostgreSQLはもともとデフォルトが小文字でSQL標準と違う
>>これはpgsqlのドキュメントにそう書いてあったのですが、

>PostgreSQL 7.2.3 ユーザガイド
>Chapter 1. SQLの構文
>http://www.postgresql.jp/document/pg721doc/user/sql-syntax.html#FTN.AEN492
>
>> PostgreSQL が引用符の付かない名前を小文字として解釈することは
>> SQL 標準とは相容れないもので、SQL 標準では引用符の付かない名前
>> は大文字に解釈されるべきだとされています。したがってSQL 標準に
>> よれば、foo は "FOO" と同じであるべきで、"foo" ではないはずなの
>> です。もし移植可能なアプリケーションを書きたいならば特定の名前
>> は常に引用符で囲むか、あるいは全く囲まないのいずれかに統一する
>> ことをお勧めします。

ちゃんとした SQLの本にも記載がありました。

SQL：1999 リレーショナル言語詳解
http://www.pearsoned.co.jp/washo/db/wa_db36-j.shtml

ちょっと立ち読みしただけですが・・　(^^ゞ

戻る