過去の桐井戸端ＢＢＳ　（桐ver.９）
29407 MYSQLを桐で使ってるのですが同じレコードの訂正がSQL側で許してもらえない ぽこちゃん 2005/03/17-21:28
色々悩みが尽きません！
今問題になってるのが、MYSQLの主キーをカウンター型にし、桐でODBC接続しております。
クライアントは桐のみで数人で使いSQLのデーターは各クライアントごとに絞り込んでフォームに表示させてます。
で、行追加でデーターを新規入力の最中、桐特有の表示に切り替えましたら、
その後同じレコードの訂正がSQL側で許してもらえません！
訂正のたびに再抽出しなければならづ困ってます！
システム事態を再構築するつもりですが、何か良いアドバイスは無いでしょうか？

やはり桐の表と比べSQLのレスポンスは比べ物にならづ他は譲れません！
カウンターだけの表を作る事も考えてますが宜しくお願いいたします。
29412 Re:MYSQLを桐で使ってるのですが！ うにん 2005/03/18-09:55
記事番号29407へのコメント
ぽこちゃんさん
>色々悩みが尽きません！

なんか楽しそう(^^;

>で、行追加でデーターを新規入力の最中、桐特有の表示に切り替えました
>ら、その後同じレコードの訂正がSQL側で許してもらえません！

これはどういう意味でしょうか。フォームから表形式編集に切り替えということ？
「新規入力の最中」というのが謎ですが。
29413 Re:MYSQLを桐で使ってるのですが！ hidetake 2005/03/18-10:06
記事番号29412へのコメント
>なんか楽しそう(^^;

楽しそうだけれど、実際に実用段階まで持って行くには相当大変そう！
特に桐だからという意味もあるのですが！　(;_;)


>これはどういう意味でしょうか。フォームから表形式編集に切り替えということ？
>「新規入力の最中」というのが謎ですが。

これは新規登録だから、実際のユニークキーとしてのカウンタが MySQL側で生成されるので
(何も工夫を加えていない状態では)、更新するためのキーをいったん登録された MySQL から取り直してこないと、
桐側からは更新ができなくなってしまうと言うことだと思います。
だから、この辺に工夫が必要になってくると思います。

それと、ODBC 経由の外部DB を桐で使う場合に毎度問題になってくると思うのは、
桐側で更新まで行う場合に、全く同じデータをクライアントで引っ張ってきた状態で、
違うタイミングで訂正を行った場合のデータ整合性の問題だと思います。
桐の場合は、その辺が条件がゆるゆるで元がすでに更新されていた場合のことが何も考えられていないので、
複数のユーザから更新が発生する場合は、後から訂正したものだけが
生きてしまうという状態になってしまいますよね。

だから、自分が更新をかける前に、元のデータにすでに更新はかかって
いないかとかのチェックが非常に面倒だろうし、桐では直接 SQL を
投げかける仕組み自体も無いので、大変だろうと・・・
29422 Re:MYSQLを桐で使ってるのですが！ hidetake 2005/03/18-18:26
記事番号29413へのコメント
> 桐では直接 SQL を投げかける仕組み自体も無いので、大変だろうと・・・

一応、桐の機能をかいくぐる SQL の投げかけに関しては下記に書いています。
http://www.fuku3.com/~habata/kbbs/kakov8/21104.htm

２種類ほど書いていますが MySQL でトリガが使えうるように
なるのは 5.0 からでしたっけ？　まだ出ていないですよね？

「ダイレクトSQLコマンドインジェクション攻撃」を用いた
手法に関しては結構条件作りとか、あとの結果のフォローも
面倒だろうし、桐の正規のの機能だけで、SQL サーバに対して
いろいろやろうとすると、私が思うに結構大変だろうと思うのです。
もちろん、共有は関係なく、データの整合性を考慮しなくて良いのでしたら、
やり方はあろうと思うのですが・・・

Access だと、更新の際も WHERE で前の値の条件を与えているので、
前の値とすでに異なっていれば更新がかけられないようになっています。
パススルークエリも使えるし！

桐で簡単にやる方法とかあるのかなぁ〜？
29423 Re:MYSQLを桐で使ってるのですが！ hidetake 2005/03/18-18:42
記事番号29422へのコメント
>桐で簡単にやる方法とかあるのかなぁ〜？

私の場合は、外部DB で使うのは PostgreSQL が主なのですが
桐の外部DB って、相当手抜きや仕様上おかしいところもあって
特に PostgreSQL 相手に使うと、桐の機能を使うだけでも障害があったりするのですが、
MySQL の場合はどうですか？
特に問題は出ていないでしょうか？

一応 MySQL も同じサーバにデフォルトで入ってはいるのですが、
一度も起動させていないのでデータベースの初期化すらも
されていない状態です。それに、ライセンスの関係も PostgreSQLよりも
面倒であったりするようですし・・・

PostgreSQL よりも MySQL の方が桐との相性が良いというのであれば、
MySQL を試してみたい気もするのですが、どうなのでしょう？
29424 多数のコメントありがとうございます ぽこ 2005/03/19-01:58
記事番号29423へのコメント
相性の件ですが、PostgreSQLは正直使った事が無いので解りませんが、
今のところ桐でのMysqlの操作は、今回の件以外では不自由しておりません
絞込み表引きも専用のフォームを作れば可能な為、面白いものが作れます。

で、悩んだ末これで良いかは解りませんが、各クライアントへ行追加専用にNullの
桐表を作り更新のたびに書出しと全行削除を繰返す様なイベント！
SQL側のカウンター項目はオートカウンターで、整合性もなんとか・・・甘いですかね〜〜？

ただ怖いのは何十人ものクライアントが一斉にSQLへの書出しで問題が起こらないかが心配です。



29425 Re:多数のコメントありがとうございます hidetake 2005/03/19-09:44
記事番号29424へのコメント
>今のところ桐でのMysqlの操作は、今回の件以外では不自由しておりません
>絞込み表引きも専用のフォームを作れば可能な為、面白いものが作れます。

そうですか、MySQL は ODBC の作りの部分では、桐の問題となる部分が
表に出ないような作りになっているのですかね？
PostgreSQL の場合は、テーブルの大文字・小文字の取り扱いでも問題が生じますし、
それ以前に ODBC ドライバのバージョンによっては全く使えないものもあります。
(最新のバージョン) Access では何のエラーも発生しないのにです。


>で、悩んだ末これで良いかは解りませんが、各クライアントへ行追加専用にNullの
>桐表を作り更新のたびに書出しと全行削除を繰返す様なイベント！
>SQL側のカウンター項目はオートカウンターで、整合性もなんとか・・・甘いですかね〜
>〜？

何をやっているのか全く理解できませんが、追加に関しては、
基本的にサーバに無いデータを追加するのでしょうから、その後に更新するための
ユニークキーを桐側でどう処理するのか、取り直すかの問題なので、
最悪追加の後で(イベントで)「再抽出」を実行すれば良いような気もします。
ほかにも、事前に MySQL 側から次に登録すべき固有番号を取得して、
それをセットして本データを追加する方法などもあると思いますが、
結局はその番号は何か？って、自分の登録お願いした条件にあたる固有番号は
どうとれたかって再抽出は必要になってくるのだと思いますし・・・

で、データの更新(訂正)に関しては、整合性は確保できるようにできたのでしょうか？

29426 Re:多数のコメントありがとうございます hidetake 2005/03/19-10:16
記事番号29425へのコメント
>で、データの更新(訂正)に関しては、整合性は確保できるようにできたの
>でしょうか？

たとえば、レコードには必ず [更新日時] の項目を持たせ、データを追加したり更新する場合は、
その時の日時をセットする。
更新日時はサーバ側の(で)日時をセットすべきでしょうし、
範囲は 1ms までとか 1μs までとか SQL サーバに関わる内容でもあると思います。

そして、データを抽出する際は [更新日時] も一緒に取ってきて、
更新が行われる際には、UPDATE 命令にサーバ側の [更新日時] の現在の値と
クライアント側がデータを取ってきた際の [更新日時] の値を比較して
一致していたら更新を行う。すなわち UPDATE に WHERE で、
このような条件を加えておく。
在庫管理で言えば、在庫数を更新する際は、取ってきた段階での在庫数と
UPDATE をかける段階での在庫数を見て、元と違っていたら更新を中止したり
確認させる処理が必要だと思います。

桐では UPDATE する際に、このような WHERE 句をどうやって条件付けるのかと？・・・
実際に UPDATE 命令内で条件を入れないと、タイミングによるズレは必ず発生しますよね。

トリガが使える SQL サーバであったら、サーバ側で桐の機能を補って
条件判断させる方法もあると思うので、桐でもサーバ側で機能を補えば、
それなりのものは可能かも知れない(それでもサーバ側での細かい処理の追加が
必要だと思う)ですけど、そうでないサーバではどのようにすれば整合性は保たれるのかが興味あります。


戻る