未指定のエラー[asp.net 2.0+access]
3795 ワード
1つのプロジェクトではaccessデータベースが使用されます.
ローカルテストでは異常は発生しませんが、サーバでリフレッシュするとこのエラーが発生します.
明らかなエラーは、データベースが閉じられていないこと、DataReaderを使用している間にリソースがタイムリーに解放されていないことです.[一般的な場合]
データベース・オペレーション・クラスが見つかりましたが、リソースがタイムリーに解放されたことは明らかです.デバッグを一歩一歩追跡しても、エラーのソースは見つかりません.
ネット上で関連問題を検索したところ、矛先は資源解放問題を指していることが分かった.
論理層ではusing文を用いて1つ以上のオブジェクトを解放するので,中にはreturnが出てくる.
これが原因ではないでしょうか?!
その結果、修正、テストの後、発見はやはりできます!しかし、ネット上で検索されたリソースの言及はusingが幽霊をやっている!個人的には無理だと思います!
その後、本当にusing文がreturnできることを確認しました.
e.g:
using(DataSet ds1 = new DataSet(),ds2 = new DataSet()){}
USing文でreturn文を使用して値を返す場合、usingは指定したオブジェクトを解放することを保証します.
それだけでなく、通常のプログラムフローが終了しても、return文を使用してジャンプしても例外を投げ出しても、using範囲内のオブジェクトは正常に解析されます.
この点ではfinallyに似ていますが、finallyよりもタイムリーです.ゴミ回収メカニズムの起動を待つ必要がなく、using文を終了するときに起動します.
参考記事:
Return Within a C# Using Statement
While writing some code earlier today I needed to return from within a using statement. Doing these sorts of things always makes me appreciate the using statement and how wonderful it really is, so I decided to write about it here. As many of you know the using statement in C# is a good tool for managing types which will be accessing unmanaged resources. Some examples of these are SqlConnections, FileReaders, and plenty of other similar types. The key to these is that they all implement the IDisposable interface. This means that they all need to be cleaned up carefully after using them.
The using statement is great because it guarantees that the declared object is disposed no matter how the execution completes. Whether you reach the end curly brace marking the end of the using statement, throw and exception, or return from a function, the using statement will call the dispose method and clean up the object.
This was important in my code because I was able to return directly from within the using statement without worrying about whether or not eh dispose method will fire. Whenever I use an object which accesses unmanaged resources I always always always put it in a using statement.
It is very important to use a using statement, because it will give you this guarantee that the object will be disposed of correctly. The object's scope will be for the extent of the using statement, and during the scope of the object it will be read-only if defined in the using statement. This is also very nice, because it will prevent this important object which manages the unmanaged from being modified or reassigned.
This is safe to do, because of how great the using statement is. No matter which return we hit we know the XmlReader will be disposed of correctly.
リンク:http://aspadvice.com/blogs/name/archive/2008/05/22/Return-Within-a-C_2300_-Using-Statement.aspx
最後に解決できないので、大きなプロジェクトを動かして、データベース接続文字列を一例モードで処理してからシーケンス化するしかありません.
データ層を再調整しました!
問題は結局解決した!
ローカルテストでは異常は発生しませんが、サーバでリフレッシュするとこのエラーが発生します.
明らかなエラーは、データベースが閉じられていないこと、DataReaderを使用している間にリソースがタイムリーに解放されていないことです.[一般的な場合]
データベース・オペレーション・クラスが見つかりましたが、リソースがタイムリーに解放されたことは明らかです.デバッグを一歩一歩追跡しても、エラーのソースは見つかりません.
ネット上で関連問題を検索したところ、矛先は資源解放問題を指していることが分かった.
論理層ではusing文を用いて1つ以上のオブジェクトを解放するので,中にはreturnが出てくる.
これが原因ではないでしょうか?!
その結果、修正、テストの後、発見はやはりできます!しかし、ネット上で検索されたリソースの言及はusingが幽霊をやっている!個人的には無理だと思います!
その後、本当にusing文がreturnできることを確認しました.
e.g:
using(DataSet ds1 = new DataSet(),ds2 = new DataSet()){}
USing文でreturn文を使用して値を返す場合、usingは指定したオブジェクトを解放することを保証します.
それだけでなく、通常のプログラムフローが終了しても、return文を使用してジャンプしても例外を投げ出しても、using範囲内のオブジェクトは正常に解析されます.
この点ではfinallyに似ていますが、finallyよりもタイムリーです.ゴミ回収メカニズムの起動を待つ必要がなく、using文を終了するときに起動します.
参考記事:
Return Within a C# Using Statement
While writing some code earlier today I needed to return from within a using statement. Doing these sorts of things always makes me appreciate the using statement and how wonderful it really is, so I decided to write about it here. As many of you know the using statement in C# is a good tool for managing types which will be accessing unmanaged resources. Some examples of these are SqlConnections, FileReaders, and plenty of other similar types. The key to these is that they all implement the IDisposable interface. This means that they all need to be cleaned up carefully after using them.
The using statement is great because it guarantees that the declared object is disposed no matter how the execution completes. Whether you reach the end curly brace marking the end of the using statement, throw and exception, or return from a function, the using statement will call the dispose method and clean up the object.
This was important in my code because I was able to return directly from within the using statement without worrying about whether or not eh dispose method will fire. Whenever I use an object which accesses unmanaged resources I always always always put it in a using statement.
It is very important to use a using statement, because it will give you this guarantee that the object will be disposed of correctly. The object's scope will be for the extent of the using statement, and during the scope of the object it will be read-only if defined in the using statement. This is also very nice, because it will prevent this important object which manages the unmanaged from being modified or reassigned.
This is safe to do, because of how great the using statement is. No matter which return we hit we know the XmlReader will be disposed of correctly.
using (XmlReader reader = XmlReader.Create(xmlPath)){ // ... Do some work... if (someCase) return 0; // ... Do some work... if (someOtherCase) return 1;}return -1;リンク:http://aspadvice.com/blogs/name/archive/2008/05/22/Return-Within-a-C_2300_-Using-Statement.aspx
最後に解決できないので、大きなプロジェクトを動かして、データベース接続文字列を一例モードで処理してからシーケンス化するしかありません.
データ層を再調整しました!
問題は結局解決した!