C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[3]: Inset後にID取得

分類:[.NET 全般]　

質問させて頂きます。

SQLでINSERTした直後にID（オートナンバー型）を取得することはできないのでしょうか？
LAST(ID)でやってみましたが、的外れな値が返ってきてしまいます。

よろしくお願いします。

■No45814 (kan さん) に返信
> 質問させて頂きます。
>
> SQLでINSERTした直後にID（オートナンバー型）を取得することはできないのでしょうか？
> LAST(ID)でやってみましたが、的外れな値が返ってきてしまいます。

他のユーザとの事を考えずに直後なら

SELECT @@IDENTITY

SQL Server2000以降で且つ、他のユーザの更新も意識する必要があるなら

SCOPE_IDENTITY()

を使えば取れると思う。SCOPE_IDENTITYはストアドだとNULLになったかもしれないから注意してね。

■No45816 (たくボンさん) に返信
> ■No45814 (kan さん) に返信
>>質問させて頂きます。
>>
>>SQLでINSERTした直後にID（オートナンバー型）を取得することはできないのでしょうか？
>>LAST(ID)でやってみましたが、的外れな値が返ってきてしまいます。
>
> 他のユーザとの事を考えずに直後なら
>
> SELECT @@IDENTITY
>
> SQL Server2000以降で且つ、他のユーザの更新も意識する必要があるなら
>
> SCOPE_IDENTITY()
>
> を使えば取れると思う。SCOPE_IDENTITYはストアドだとNULLになったかもしれないから注意してね。

ありがとうございます。
mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。

SCOPE_IDENTITY()でやってみましたが、未定義関数…とエラーになってしまします。

■No45817 (kan さん) に返信
> mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。

mdb だとしたら、"SELECT @@IDENTITY" にて、直前に採番された値を取得できます。
http://yaplog.jp/orator/archive/12
http://support.microsoft.com/kb/815629

■No45817 (kan さん) に返信
> mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。

mdbファイルがこわれるので運用に耐えられないと思います。

> SCOPE_IDENTITY()でやってみましたが、未定義関数…とエラーになってしまします。

Accessのmdbを使わずにSQLと書いていたので回答者の方がSQL Serverの情報を提供しているからです。
Accessには類似の機能がないと思います。

■No45819 (はつねさん) に返信
> ■No45817 (kan さん) に返信
>>mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。
>
> mdbファイルがこわれるので運用に耐えられないと思います。
>
>
>>SCOPE_IDENTITY()でやってみましたが、未定義関数…とエラーになってしまします。
>
> Accessのmdbを使わずにSQLと書いていたので回答者の方がSQL Serverの情報を提供しているからです。
> Accessには類似の機能がないと思います。
>

> mdbファイルがこわれるので運用に耐えられないと思います。
とはどういことでしょうか？？

他ユーザーと言っても2.3人ですし、INSERT後すぐにSELECT @@IDENTITY しているので問題ないとは思いますが、テーブルをロックする等他に制御する方法はあるんでしょうか？

■No45821 (kan さん) に返信
> ■No45819 (はつねさん) に返信
>>■No45817 (kan さん) に返信
> >>mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。
>>
>>Accessのmdbを使わずにSQLと書いていたので回答者の方がSQL Serverの情報を提供しているからです。
>>Accessには類似の機能がないと思います。

ごめんなさい。SQL Serverだと思ってました。ACCESSなら@@IDENTITYですね。
クライアントのプログラムはVBAマクロ？それとも他の何か言語？

■No45869 (たくボンさん) に返信
> ■No45821 (kan さん) に返信
>>■No45819 (はつねさん) に返信
> >>■No45817 (kan さん) に返信
>>>>mdbを使用していまして、複数ユーザがINSERTを行う可能性があります。
> >>
> >>Accessのmdbを使わずにSQLと書いていたので回答者の方がSQL Serverの情報を提供しているからです。
> >>Accessには類似の機能がないと思います。
>
> ごめんなさい。SQL Serverだと思ってました。ACCESSなら@@IDENTITYですね。
> クライアントのプログラムはVBAマクロ？それとも他の何か言語？

いえいえ、こちらこそありがとうございます。

クライアントはVB.netです。

■No45871 (kan さん) に返信
> クライアントはVB.netです。

接続には何を使ってます？ADOかな?
ADOを使ってACCESSの@@IDENTITYを管理する方法があったので書いておきます。（昔読んだ記憶があるけどすっかり忘れてた）

http://msdn.microsoft.com/ja-jp/library/ms971502.aspx#manidcrisis_topic2

ACCESSは既存システムの修正くらいしか使わないんで、詳しくないけど最近のACCESSは少しは壊れる頻度少なくなったんじゃなかったっけ？JET経由なら接続ごとに@@IDENTITY管理されるらしいから競合による心配はなさそうだけど。

>>mdbファイルがこわれるので運用に耐えられないと思います。
> とはどういことでしょうか？？
>

この話よく聞くけど、ちゃんとした根拠は知らないんだよねえ。
私も知りたい。

↓とりあえず探してみた。

http://support.microsoft.com/kb/303528/ja

「ネットワーク環境におけるその他の推奨事項」のところに、こういう記述があった。

> Microsoft Jet は、高い負荷がかかるサーバーアプリケーション、多くのプロセスによって
> 同時に使用されるサーバーアプリケーション、毎日 24 時間無停止で実行されるサーバー
> アプリケーションでの使用は想定されていません。

> インターネットインフォメーションサービス (IIS) のように高い負荷がかかるアプリケーションで
> Microsoft Jet を使用すると、次のいずれかの問題が発生する可能性があります。
> ・データベースの破損
> ・IIS がクラッシュする、動かなくなるなどの安定性の問題
> ・IIS サービスの再起動を必要とする、有効なデータベースへのドライバの突発的または恒久的な接続障害

単に共有フォルダに置いて使うようなやり方については、特にダメとか非推奨とかいった資料は見つけられなかった。
やり方は↓に載ってたけど。

http://office.microsoft.com/ja-jp/access/HP051882881041.aspx?pid=CH062526671041

■No45952 (みきぬさん) に返信
> >>mdbファイルがこわれるので運用に耐えられないと思います。
>>とはどういことでしょうか？？
>>
>
> この話よく聞くけど、ちゃんとした根拠は知らないんだよねえ。
> 私も知りたい。

俺も知りたい。
レコード数やファイルサイズが大きくなると壊れやすいとか書いてるけど、直接の原因は別なのかも。
VB4の頃はvar型のメモリリークとかあったし、連続稼動用に設計されていないってのはこの辺が原因なのかも。Win95まではOSのメモリ管理も微妙だったし。

連続稼動してると一太郎のプロセスがメモリリークしてて、アプリケーション領域を超えてメモリ壊してたって記憶ならあるけどｗ

# 「ｓｈｏｐ」が含まれていると投稿できないらしいので、
# URL の一部を「%73hop」表記に変更しました。

■No45928 (たくボンさん) に返信
> ADOを使ってACCESSの@@IDENTITYを管理する方法があったので書いておきます。（昔読んだ記憶があるけどすっかり忘れてた）
> http://msdn.microsoft.com/ja-jp/library/ms971502.aspx#manidcrisis_topic2
その文書は ADO の物ではなく、ADO.NET の物だと思いますよ。
(内容的には、No45818で示した KB815629 とほぼ同じ内容のようですね)

> 最近のACCESSは少しは壊れる頻度少なくなったんじゃなかったっけ？
「ACCESS」という表現には違和感を感じますが、それには目を瞑るとして。

扱い方にもよるのでしょうね。他の人はどうなのか分かりませんが、
私自身の経験では、破損回数がそれほど多いとは感じていません。
(破損回数ゼロという訳ではないですが、それは SQL Server や Oracle の場合にも言えますし)

もちろん信頼性という点で見れば、SQL Server や Oracle 等の方が上でしょう。

ゆえに総合的に判断した結果、はつねさんが仰るように『運用に耐えられない』と
判断されてしまう場合もあるでしょうし、あるいは「大丈夫みたいだけれども、
危険と言われている事をあえてやる必要も無いので、MSDE にしておこう」といった
判断が下される事もあるとは思います。

■No45952 (みきぬさん) に返信
> 特にダメとか非推奨とかいった資料は見つけられなかった。
非推奨といった記述は見つかりませんでしたが、Office のヘルプや Microsoft の
技術情報などを読み返してみると

| 停電や電力不安定などの環境的要素、Access データベースの不適切な方法での終了、
| ディスクやネットワークの障害などによりデータベースファイルが破損した状態に
| なる場合があります。また、Access データベースの使用中に生じた空き領域が
| 蓄積され、それが原因で破損につながる場合もあります。

といった記載ならばありますね。また、みきぬさんが示された URL にも

| ネットワークファイルサーバー上のファイルを 2 つ以上のクライアントが
| 共有している場合、Opportunistic Locking を使用すると、Jet データベースが
| 破損する危険性が高くなることがあります。

とありますね。

このほか、(ダメなどという話ではありませんでそたが)ネットワークでの利用上の
注意点について、urn:isbn:4756121869 の第6章に解説がありました。

■No45956 (たくボンさん) に返信
>>>>mdbファイルがこわれるので運用に耐えられないと思います。
>>>とはどういことでしょうか？？
>>この話よく聞くけど、ちゃんとした根拠は知らないんだよねえ。
>>私も知りたい。
> 俺も知りたい。
根拠という程の物ではないですが…。

破損頻度が上がるとされているのは、マルチユーザーで利用した場合ですね。
それも同一端末上からではなく、共有フォルダ上で利用した場合。
http://www.naboki.net/access/achell/achell-02.html

同一端末からの複数アクセスの場合でさえ、OSのライトキャッシュによる遅延が
問題となる事があります。
http://www.canalian.com/work%73hop/access/JetCache.html
これがネットワーク越しのアクセスになると、通信による遅延やネットワーク障害などの
可能性も加わるため、問題はさらに大きくなると思われます。
(それが破損に直接繋がるかどうかはわかりませんけれども)

Oracle 等であれば、データベースエンジンはサーバー側にあり、クライアントはそれを呼び出すだけです。
しかし Jet はクライアント側にエンジンがあります。トランザクションの管理も各端末上で行われます。
そのため Jet のようなファイル共有型データベースでは、書き込みまでの時間差があれば、
データの不整合が起きてしまう可能性が高くなってしまうのだろう…と想像。

本題じゃなくてすみません。

■No45952 (みきぬさん) に返信

> 単に共有フォルダに置いて使うようなやり方については、特にダメとか非推奨とかいった資料は見つけられなかった。

探されたリンク先の関連情報にある

283849 (http://support.microsoft.com/kb/283849/ ) [ACC2003] Access 2002 以降の破損したデータベースをトラブルシューティングおよび修復する方法

に書かれている破損の主な原因を見る限り、単なるファイルである MDB で壊れることがあるのは仕方がなさそうに思いますし、バグ的なものでもなさそうに思います。（RDBMS においても壊れることはありますが、自動的にリカバリーされることで気付かない場合があります。）
MDB にアクセスするエンジンのバージョンがクライアントごとに異なるかもしれないということも、考えるだけで怖い話です。

私には壊れた経験はありませんが、それは全クライアントの環境がほぼ同じで、アクセスの競合が少なく、アプリケーション環境がたいてい正常動作しているからかもしれません。
ただし、SQL Server 等の代替手段がとれるのでしたら、それにこしたことはないと思います。

■No45968 (魔界の仮面弁士さん) に返信

> 同一端末からの複数アクセスの場合でさえ、OSのライトキャッシュによる遅延が
> 問題となる事があります。

Jet の Write Cache が不都合につながることは想像できますが、ＯＳのキャッシュが問題になるのは想像できないです。ＯＳのライトキャッシュって、おもにディスクへの遅延書き込みのことですよね？
遅延書き込みをするのは各クライアントではなく、共有フォルダを公開しているＯＳだと思うので、別プロセスからのアクセスで問題が発生するということは信じられないです。
遅延された書き込みが実際に行われるまでに電源が切られた場合、その情報は無くなっちゃいますけど、それは MDB に限った事じゃないですし。

■No45956 (たくボンさん) に返信
> ■No45952 (みきぬさん) に返信
>>>>mdbファイルがこわれるので運用に耐えられないと思います。
> >>とはどういことでしょうか？？
>>
>>この話よく聞くけど、ちゃんとした根拠は知らないんだよねえ。
>>私も知りたい。
>
> 俺も知りたい。

mdbファイルにアクセス中にネットワーク接続が切れた場合、中途半端な状態
でデータが書き込まれる可能性があります。例えばmdbファイルに書き込みし
ているのにクライアントPCのLANケーブル抜いたり電源落としたりしたときで
す。
このあたりは http://support.microsoft.com/kb/303528/ja の「ネットワー
ク環境におけるその他の推奨事項」あたりに
-------引用開始
ネットワーク経由で複数のクライアントプロセスが同じ共有ファイルの読み
取り、書き込みおよびロックを実行します。プロセスが処理を完了できないと、
ファイルが不完全な状態または破損した状態のままになることがあります。
次のいずれかの原因で処理を完了できないことがあります。
-------引用終了
とあります。
ちなみに、その下あたりにある「サーバーアプリケーション」には、当然、
ファイルサーバー自身も含まれます。

あと最適化しないとファイルサイズが大きくなっていくから最適化があります。
最適化が必要な点は、
http://support.microsoft.com/kb/303528/ja
にもかかれていますね。

ローカルにある（もしくはサーバーにあっても１台のＰＣからしか使ってない）
mdbファイルを使うアプリだったら最適化や修復を動作の中に組み込めますが、
最適化にしても修復にしても他で使っているときは使えません。
IISから使っているのならばIISをとめてメンテとか称しておこなうことも可能
かも知れませんが（でもIISからの利用すら推奨されていない）ファイル共有
ではそう簡単にアクセス遮断できないのも悩ましいところです。

C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[3]: Inset後にID取得

過去ログには書き込み不可