[Command] オブジェクトの [CommandText] プロパティに指定したコマンドを実行します。
あらかじめ [CommandText] プロパティにコマンドが指定されている必要があります。

レコードセットオブジェクトの参照を返します。

指定項目	内容（全て省略可能です）
RecordsAffected	Long 型の変数を指定します。 実行されたコマンドにより影響を受けたレコード数が格納されます。
Parameters	バリアント型の配列にパラメーターを格納して指定します。 SQL ステートメントにパラメーターとして引き渡されます。
Options	Long 型の定数を指定します。 CommandTextプロパティを評価する方法とメソッドの実行を制約する項目を指定できます。

[Connection.Execute] と [Command.Execute] は，引数構成が多少異なりますが提供する機能は基本的に同等です。

プロバイダに固有なコマンドタイプを使用する場合には [Connection.Execute] メソッドを使用する必要があります。
一方，出力パラメーターを含む高度なコマンドを実行するには [Command.Execute] を利用する必要があります。

パフォーマンスの観点からは，１回きりしか実行しないコマンドはコマンドの状態情報を保持しない [Connection.Execute] メソッドを利用するべきで，
複数回実行または幾つかのコマンドを連続的に実行する場合は再利用可能な [Command] オブジェクトを利用することによりオーバーヘッドを防げます。

項目	Connection.Execute	Command.Execute
サポートするコマンドタイプ	クエリ テーブル ファイル SQLステートメント ストアドプロシージャ プロバイダ固有コマンド	クエリ テーブル ファイル SQLステートメント ストアドプロシージャ
最適実行回数	単発コマンド	複数回実行コマンド 多種類コマンドの連続実行
パラメーター使用条件	入力パラメーターのみ可能	出力パラメーターを含む高度パラメーターを使用可能

[Connection.Execute] と [Command.Execute] 共に結果を返さないコマンドに対しても閉じたレコードセットを返します。これはSetステートメントによって明示的に戻り値を格納した場合だけでなく，行を返さない構文を指定している場合でも暗黙にレコードセットが作成されています。返却レコードセットが用意されると，プロバイダがレコードセットプロパティを評価するために無用なオーバーヘッドが生じます。メソッド実行時のOption項目にadExecuteNoRecordsを指定することによって，レコードセットを作成しない制約をかけることができパフォーマンスが向上します。

cmdSQL.CommandText="INSERT INTO [TBL] VALUES(1,2,3)"	･･･�@
cmdSQL.Execute ，，adCmdText + adExecuteNoRecords	･･･�A
						

[Connection.Execute] の第２引数，[Command.Execute] の第１引数に指定する Long 型の変数 [RecordsAffected] には，[Execute] メソッドの実行後にそのコマンドによって影響を受けたレコード数が格納されます。

RecordsAffected	状態
-1	レコードの読み取りなど，レコードに影響を及ぼさないコマンドが実行されたときの値
0	レコードに影響を及ぼすコマンドが実行されたものの，結果的にレコードが更新されなかったときの値
有効値	レコードに影響を及ぼすコマンドが実行されて，実際に影響を受けたレコードの数

cmdSQL.CommandText="SELECT * FROM [TBL] "	･･･�A
cmdSQL.CommandText="UPDATE [TBL] SET [Field1]='B'WHERE [Field1]='A'"	･･･�B
cmdSQL.CommandText="INSERT INTO [TBL] VALUES(1,2,3)"	･･･�C
cmdSQL.Execute lngAffected，，adCmdText･･･�@
						

SQL Server 用の OLE DB プロバイダです。SQL DB Engine にアクセスします。

Ａ　サーバーカーソル
サーバーカーソル（UseServer）では静的カーソル（OpenStatic）が読取専用（ReadOnly）でしか使用できません。
静的カーソルを他のロックタイプと併用すると，カーソルタイプがキーセットカーソル（OpenKeyset）に自動的に置き換えられます。

Ｂ　クライアントカーソル
クライアントカーソル（UseCliant）では静的カーソルのみ使用できます。他のカーソルタイプを指定しても全て静的カーソルに置き換えられます。
また，排他的ロック（LockPessimistic）は最初から静的カーソルと組み合わせて指定したときのみ使用できます。
置き換わる他のカーソルタイプと組み合わせて指定した場合は，全て共有的バッチロック（LockBatchOptimistic）に同時に置き換えられます。

Access用のOLE DBプロバイダです。Jet DB Engineにアクセスします。

Ｂ クライアントカーソル
クライアントカーソルでは静的カーソルのみ使用できます。
他のカーソルタイプを指定しても全て静的カーソルに置き換えられます。

排他的ロックが使用できません。
全て共有的バッチロックに置き換えられます。

レコードセットがサポートする機能を調べるためのメソッドです。

[Supports] メソッドは，プロバイダが該当する機能を提供できるかどうかを返すので，特殊な条件下では，サポートすると示された機能が実際には実行できない場合があります。
（ODBC 制御下で複数テーブル結合を使用した場合，[Supports] メソッドは更新可能を示しますが，ODBC クラスでは更新をサポートしていません）

また，前項で解説したタイプの強制変更の際も，強制変更された場合と，強制変更先をはじめから指定していた場合とでは [Supports] の結果が異なる場合が出てきます。
以下に，Supportsが示す内容を解説します。

Ａ　[AddNew]，[Find]，[Update]，[Delete] 及び [Bookmark]
それぞれ該当する ADO メソッドが使用可能かどうかを示します。

Ｂ　[MovePrevious and Move]
[MoveFirst]，[MovePrevious]，[Move] 及び [GetRows] メソッドを使ってカレントカーソルを後方に移動できるかどうかを示します。
[Bookmark] による後方移動は含まれません。

Ｃ　[AbsolutePosition and AbsolutePage]
[AbsolutePosition] と [AbsolutePage] のプロパティが使用できるかどうかを示します。

Ｄ　[Holding Records]
確定されていない全ての変更をコミットせずに，レコードを追加したり別の位置のレコードを変更できるかを示します。

Ｅ　[Notifications]
プロバイダがレコードセットイベントをサポートできるかを示します。

Ｆ　[Resyncing data]
[Resync] メソッドを使って，レコードセットの元になる値を [UnderlyingValue] に格納しなおせるかどうかを示します。

Ｇ　[Batch Updating]
[UpdateBatch] と [CancelBatch] を利用してバッチ更新が可能かどうかを示します。

非接続レコードセットは，有効化されているデータベースとの接続を持たないレコードセットです。
非接続レコードセットは，データベースとの接続に拘束されず，データベースが置かれているサーバー上のリソースを消費することもありません。
このため，クライアント／サーバーアプリケーションもしくは３階層アプリケーションにおいて，長時間使用されるデータをクライアントに渡す場合にサーバーリソースの消費を抑えることができます。
また，非接続レコードセットは主としてバッチ更新モードとセットで使用され，クライアント側で更新をプールしている際にデータベースを保持しつづけたり，更新ごとにデータベースに更新を送信したりしないために無用なリソースの消費を回避できます。
非接続レコードセットはクライアントカーソルで使用するため，レコードセットのコピーがクライアント側に一時保存されます。

非接続レコードセットはクライアントカーソルでのみ作成できます。
よって，カーソルタイプは静的カーソルに固定されます。

また，非接続レコードセットの利点を生かすためにはバッチ更新モードにする必要があります。
クライアント／静的カーソル，バッチ更新のレコードセットを作成したら，そのレコードセットの [ActiveConnection] プロパティを明示的に [Nothing] に設定します。
これでレコードセットは現在の接続から切断されます。

データベースに再接続するには，有効な [Connection] オブジェクトを [ActiveConnection] プロパティに設定しなおせば再接続が行われます
（再接続を行う際の [Connection] オブジェクトの検証については以降で詳説します）。

Dim cnSQL As ADODB.Connection
Dim rsSQL As ADODB.Recordset
Const strCN_STRING As String = "Provider=SQLOLEDB.1;" & _
		"Data Source=SRVNAME;Initial Catalog=DBNAME;"
Const strQUERY As String = "SELECT * FROM [TBL]"

Set cnSQL = New ADODB.Connection
Set rsSQL = New ADODB.Recordset
cnSQL.Open strCN_STRING
rsSQL.CursorLocation = adUseClient		･･･�@
rsSQL.Open strQUERY,cnSQL,adOpenStatic,adLockBatchOptimistic,adCmdText		･･･�A
Set rsSQL.ActiveConnection = Nothing		･･･�B
						

接続を解除しても，レコードセットは開いたままになります。
よって，フィールド値の上書き，レコードの追加，削除を行ってレコードセットを編集することができます。
また，バッチ更新モードを設定しているので１レコードの編集ごとに変更をデータベースに送信する必要はありません。
[UpdateBatch] が自動的にローカルキャッシュの変更を全て確定します。
必要な更新を全てローカルコピーのレコードセットに格納します。

全ての変更を格納してデータベースに送信する準備が整ったら，非接続レコードセットを再接続します。
[ActiveConnectiopn] プロパティに，新たに有効化された接続情報を引き渡すことによって再接続が行われます。
再接続したレコードセットで [UpdateBatch] メソッドを呼び出すことによって，レコードセットに加えられた全ての変更がデータベースに送信されます。

Dim cnSQL As ADODB.Connection
Const strCN_STRING As String = "Provider=SQLOLEDB.1;" & _
		"Data Source=SRVNAME;Initial Catalog=DBNAME;"

･･･（必要な変更を全て格納します）･･･

Set cnSQL = New ADODB.Connection
cnSQL.Open strCN_STRING		･･･�@
Set rsSQL.ActiveConnection = cnSQL		･･･�A
rsSQL.UpdateBatch		･･･�B
						

非接続レコードセットはデータベースとの接続を解除してバッチ更新モードを利用しているため，変更しているレコードの動的なロック制御を行っていません。
よって，接続を解除している間に他のユーザーがデータベースの値を変更することが可能です。
レコードセットの接続が解除されてから他のユーザーが変更を行ったレコードに対して [UpdateBatch] が更新を送信すると，競合が発生します。

バッチ更新モードではレコードセットを作成した時点でのレコードの値を保持しておいて，現在のデータベース上のレコードの値と比較することによって他のユーザーによる更新を検知します。
競合が発生した場合，[UpdateBatch] メソッドは更新可能な全てのレコードを更新してからエラー −2147217864を起こします。

また，競合の情報を [Connection] オブジェクトの [Errors] オブジェクトに格納し，各レコードの [Status] プロパティのステータス情報を更新します。
（ADO のヘルプでは，プロバイダは送信する全ての変更で競合が発生したときのみプログラムの実行を停止すると記述されていますが，実際には一部レコードのみが競合した場合にもプログラムは停止されてしまいます）

競合が発生した場合は，競合解決のための方針に従って適切にレコードセットを再評価しなければなりません。
競合を評価するために，レコードセットの [Filter] プロパティを使用します。
競合を起こしたレコードのみに絞り込む場合は [Filter] プロパティに [adFilterConflictingRecords] を指定します。
直前に実行された [UpdateBatch] によって影響を受けたレコード全てを評価する場合は [adFilterAffectedRecords] を使用します。

Private Sub SubmitChange()
On Error Goto Catch		･･･�@

･･･（必要な変更を全て格納します）･･･

    Set rsSQL.ActiveConnection = cnSQL
    rsSQL.UpdateBatch		･･･�A
Finally:

･･･ ※ 資源解放などの終了処理は省略してあります

    Exit Sub
Catch：
    Select Case Err.Number
    Case −2147217864 '←実際には定数にすべきです		･･･�B
        rsSQL.Filter = adFilterConflictingRecords		･･･�C

･･･（競合したレコードの情報を取得します）

        rsSQL.Resync adAffectGroup, adResyncUnderlyingValues		･･･�D
        rsSQL.UpdateBatch		･･･�E
        rsSQL.Filter = adFilterNone		･･･�F
    Case Else
        'その他のエラー処理を行います
    End Select
    Goto Finally
End Sub
								

･･･ ※ Catch以降のエラー処理のみ記述しています
Catch：
    Select Case Err.Number
    Case -2147217864 '←実際には定数にすべきです
        rsSQL.Filter = adFilterConflictingRecords		･･･�@
        rsSQL.Resync		･･･�A
･･･（競合したレコードのローカルコピーの値をFields(Index).Valueからデータベース上の現在の値をFields(Index).UnderlyingValueから取得します）
        rsSQL.Requery		･･･�B
        rsSQL.Filter = adFilterNone				･･･�C
    Case Else
        'その他のエラー処理を行います
    End Select
    Goto Finally
End Sub
								

･･･ ※ Catch以降のエラー処理のみ記述しています
Catch：
    Select Case Err.Number
    Case −2147217864 '←実際には定数にすべきです		
        rsSQL.Filter =adFilterAffectedRecords		･･･�@
        Do Until rsSQL.EOF
            If (rsSQL.Status And adRecConcurrencyViolation + adRecModified) _
			= adRecConcurrencyViolation + adRecModified Then

･･･競合を起こした場合の処理を記述します	･･･�A

            ElseIf (rsSQL.Status And adUnmodified) Then

･･･同じ値に更新した場合の処理を記述します	･･･�B
･･･※ その他必要があるだけ制御を追加します
            End If
            rsSQL.MoveNext
        Loop
        rsSQL.Filter = adFilterNone		･･･�C
    Case Else
    'その他のエラー処理を行います
    End Select
    Goto Finally
End Sub
								

非接続レコードセットが保持する接続情報を検証するために以下の実験を行ってみました。

※ 接続したテーブルは Srv01，Srv02 共に同名，同定義のテーブルとする
※ 受け入れ側のテーブルは全て空テーブルとする
※ 想定した機能は Srv01 のテーブルから Srv02 のテーブルにレコードをフルコピーすること

レコードセット [Fields] コレクションの Index を利用して多数のレコードの値を取得／更新する場合，各レコードごとに [Fields] コレクションの先端 Index 0 から走査が行われるためにオーバーヘッドが生じます。
このオーバーヘッドは，必要となる Index を持つ [Field] アイテムを別の [ADODB.Field] 型変数に事前バインドすることによって解消できます。

Do Until rsSQL.EOF
    Debug.Print rsSQL.Fields(0)
    Debug.Print rsSQL.Fields(1)
    Debug.Print rsSQL.Fields(3)
    Debug.Print rsSQL.Fields(5)
    rsSQL.MoveNext
Loop
						

Dim fdNo0 As ADODB.Field
Dim fdNo1 As ADODB.Field
Dim fdNo3 As ADODB.Field
Dim fdNo5 As ADODB.Field		･･･�@

････

Set fdNo0 = rsSQL.Fields(0)
Set fdNo1 = rsSQL.Fields(1)
Set fdNo3 = rsSQL.Fields(3)
Set fdNo5 = rsSQL.Fields(5)		･･･�A

Do Until rsSQL.EOF
    Debug.Print fdNo0
    Debug.Print fdNo1
    Debug.Print fdNo3
    Debug.Print fdNo5		･･･�B
    rsSQL.MoveNext
Loop
						

不要なデータ転送と，不要なログ保存はデータベースリソースを無駄遣いし，パフォーマンスを低下させます。
例えば，レコードの挿入の際に [AddNew] →フィールド編集→ [Update] という流れで行うと，[AddNew] から，1フィールドの編集動作までがひとつひとつ SQL Server に送信されます。
また，レコードセットが作成されていない状況から新たにレコードセットを作成して挿入を行うとレコードセットに含まれる膨大なデータが転送されてリソースの無駄遣いが発生します。
既存レコードの更新についても同様に，１フィールドごとの更新から [Update] を行うと，１つ１つのステップがひとつひとつ送信され，ステップの移動ごとにオーバーヘッドが生じます。
これらレコードの挿入及び更新には，T-SQL の INSERT 文や UPDATE 文を使用します。
T-SQL コマンドを利用すれば，挿入・更新動作を１ステップとして実行するためにリソースを効率的に利用できます。
但し，T-SQL コマンドで実行したデータベースへの変更を，現在作成されているレコードセットに反映するためには（カーソルタイプにも依存しますが）[Recordset] オブジェクトの [Requery] メソッドを実行する必要があります。
既存レコードセットが巨大な場合は，再取得するレコードセットの情報の方が大きい場合があるので注意が必要です。
レコードセットが用意されていない状況では，T-SQL コマンドを利用し，レコードセットが既にある場合は，再取得するレコードセットの大きさを評価して使い分ける必要があります。

DELETE 文を WHERE 条件をつけずに実行すると，指定したテーブル内の全てのレコードを削除します。
しかし，DELETE 文は１度に１レコードずつ削除して，削除エントリを１レコードずつトランザクションログに記録します。
一方，TRUNCATE 文はデータを格納する領域を解除することによってテーブル全体のレコードを削除するため，トランザクションログには領域の削除のみが記録されます。
DELETE 文はテーブル内の Identity のカウンタ値を保存するのに対して，TRUNCATE 文はカウンタを初期値にリセットします。
また，TRUNCATE 文はページ全体を削除するためにトリガを発動できず，この他外部キー制約が掛けられているテーブルには使用できません。
TRUNCATE 文はデータ内容を削除するのみなので，テーブル定義，制約，インデックスなどは保存されます。

SELECT ＊ を使用すると，実際には参照も更新もされない無駄な情報がネットワーク経由で送信されることになります。
ローカルに使用されるレコードセットの取得などの場合は必要最低限のフィールドを指定することによって，送信される情報量を抑える必要があります。
レコード数のカウントを取る場合にも，"SELECT COUNT([ID])"のように一意なフィールドを指定するなどして，SQL Server内部の処理も最小化するように努めます。
（SELECT COUNT(*) と SELECT COUNT([ID]) のどちらが早いのかというのはもっと込み入った議論があるようです）

テーブルの中で上位／下位何レコードかを利用することがわかっている場合は，T-SQL の TOP 文や [Recordset] オブジェクトの [MaxRecords] プロパティを利用します。

このクエリで先頭 10 レコードを取得します。
ORDER BY 句と組み合わせることによって，昇順 10 レコードや降順 10 レコードを取得することも可能です。

[Recordset] オブジェクトの [ActiveConnection] プロパティは [Recordset] が閉じている場合は読み書き可能で，開いている場合は読取専用になります。
これの唯一の例外が，非接続レコードセットを作成する場合で，[CursorLocation] プロパティが [UseCliant] を使用している場合のみ上書きが可能になります。
（Nothing以外の値も上書き可能です。）

[Connection] オブジェクトの [Close] メソッドを呼び出すと，[Recordset] は自動的に閉じた状態に変更され，[ActiveConnection] プロパティは Nothing にセットされます。
よって，[Recordset] が閉じられる前に [Connection] の [Close] が行われても比較的オブジェクトの呼び出し構造に不整合は生じません。
しかし，[Connection] の [Close] が行われない状況において，何らかの理由で [Connection] オブジェクトが解放されてしまっても，[Recordset] オブジェクトは影響を受けません。
参照先のコネクションが破棄されているにも関わらず，[ActiveConnection] プロパティは元の接続情報を保持し，条件によっては [Update] メソッドや [UpdateBatch] メソッドが正常に動作する場合があります。
（更新もサーバーに反映されてしまいます）

このことから，[Recordset] は [Connection] オブジェクトから接続情報を完全に参照しているわけではなく，一部を共有しつつ，内部的にも接続情報を保存していると言えます。
[Connection] オブジェクトが破棄されているにもかかわらず，機能の一部が呼び出せるレコードセットができてしまうことから，オブジェクト解放の順序を正確に記述しないと，適切な ADO 運営はできません。

上記のようなコードには安全上致命的な欠陥が存在します。
テキストボックス txtName に VB では MaxLength プロパティの設定や，VBA ではコードによる入力値のチェックなどが組み込まれていないと，意図しない SQL 文が実行されてしまう可能性があります。
意図しない SQL 文とは，データベースのレコードを改竄・破壊したり，最悪の場合データベースサーバー自体にも被害を及ぼすような SQL 文を言います。
上記のようなコードを実装したアプリケーションで，txtNameに

という値を挿入すると，完成する SQL コマンドは

となります。
これは１行にいくつかの SQL 文を続けて書く「；」を使用した手法で，
「[NAME]フィールドが空のレコードを選択した後，[TBL]テーブルのレコードを削除しなさい」というコマンドになります。
よって，この入力値がチェックを通ってしまうようなことがあると，データベースが簡単に破壊されてしまいます。

一方，システムストアドプロシージャを利用すると

というように，SQL Server が稼動しているサーバー上で任意の Shell コマンドを実行することができます。
この Shell コマンドにフォーマットを実行するようなコマンドを投げれば，サーバー自体に致命的な被害が及んでしまいます。

これを防ぐために，

• 入力値のチェックは厳密に何重にも行う
• 特殊文字「'」，「￥」はエスケープするために「''」，「￥￥」に置き換える
• アプリケーションに使用させるデータベースアカウントには必要最低限のデータベースロールしか与えない

ADO をはじめ，AactiveX に根ざすオブジェクト変数は全て，使用したら適切に解放しなければなりません。
適切な解放が行われないと，アプリケーションを閉じた後もサーバーへの接続が残ってしまったり，オブジェクトがメモリの一部を占拠したままアクセスできなくなったり，他のアプリケーションに影響を与えるなどの不具合が生じます。
ADO では [Open] メソッドを呼び出して使用するオブジェクトには [Close] を呼び出して，最終的に全てのオブジェクトに対して Set Nothing によるメモリからの削除を行う必要があります。
解放手順とコードについては次々項「共通終了処理」で解説します。

１つの [Connection] に関連のある全ての ADO 操作でのプロバイダが返すエラーは [Connection] の [Errors] コレクションに返されます。
この [Errors] コレクションに格納された個々の [Error] オブジェクトを参照することによって，プロバイダを介して返される SQL の内部エラー情報を取得することができます。
以下のコードでは，各 [Error] オブジェクトの情報をデバッグのためにイミディエイトウィンドウに表示しています。

If Not (cnSQL Is Nothing) Then
    For intI = 0 To cnSQL.Errors.Count - 1
Debug.Print "cnSQL Error Index：" & intI
        Debug.Print cnSQL.Errors.Item(intI).Number		･･･ VBエラー番号
        Debug.Print cnSQL.Errors.Item(intI).Description		･･･ エラー説明
        Debug.Print cnSQL.Errors.Item(intI).Source		･･･ エラーを起こした元
        Debug.Print cnSQL.Errors.Item(intI).NativeError		･･･ 内部エラー番号
        Debug.Print cnSQL_A.Errors.Item(intI).SQLState		･･･ 関連オブジェクトのステータス
    Next
End If
						

ADO オブジェクトの解放処理は，エラーが発生して緊急にプロシージャを終了する場合にも，プロシージャの実行が正常に終了した場合にも共通に行う必要があります。
前者の場合は，通常の解放処理を行う前にエラーを適切に処理する必要があるということのみ違いがあります。

よって，ADO にアクセスするプロシージャでは，正常終了の場合には終了処理を行ってプロシージャを出る。
エラーが発生した場合はエラー処理にジャンプした後，残りのプロシージャのステップをとばして，終了処理に再びジャンプする必要があります。

このような処理方法は，Ｃ++などのオブジェクト指向言語には一般的な処理で，例外処理という形態で実装されています。
VB.NET についても，Try〜Catch〜Finally という構造で（Try：メイン処理 Catch：エラー処理 Finally：共通終了処理）例外処理が実装されています。
しかし，通常の VB6.0 環境ではこの形態のエラー処理は実装されておらず，擬似的に実現するしかありません。
Goto ステートメントと行ラベルを利用して，以下のように擬似的な共通終了処理を実装します。

この型でコーディングすることによって，共通終了処理が明確化され，より安全な ADO 運用ができるようになります。

Private Sub ADOAccess( )
On Error Goto Catch		･･･�@
    Dim cnSQL As ADODB.Connection
    Dim cmdSQL As ADODB.Command
    Dim rsSQL As ADODB.Recordset

    ･･･メイン処理		･･･�A

Finally:		･･･�B
    If Not(rsSQL Is Nothing) Then
        If rsSQL.State <> adStateClosed Then rsSQL.Close
        Set rsSQL = Nothing
    End If

    If Not(cmdSQL Is Nothing) Then
        Set cmdSQL = Nothing
    End If

    If Not(cnSQL Is Nothing) Then
        If cnSQL.State <> adStateClosed Then cnSQL.Close
        Set cnSQL = Nothing
    End If
    Exit Sub
Catch:		･･･�C
    If Not (cnSQL Is Nothing) Then
        For intI = 0 To cnSQL.Errors.Count - 1
    Debug.Print "cnSQL Error Index：" & intI 
            Debug.Print cnSQL.Errors.Item(0).Number
            Debug.Print cnSQL.Errors.Item(0).Description
            Debug.Print cnSQL.Errors.Item(0).Source
            Debug.Print cnSQL.Errors.Item(0).NativeError
Debug.Print cnSQL_A.Errors.Item(0).SQLState
        Next
    End If
    ･･･その他のエラー処理
    Goto Finally
End Sub