VB.NETでSQL SERVERのSP(ストアドプロシージャ)からRETURN値を受け取る

 SQL SERVERを使ったプログラムを相当作っていたのだが、SPが返すRETURN値を受け取る方法を知らなかった。今回、初めて知ったのでメモ。

        Dim rc As Integer = 0 ' RETURN値
        Using connection As New SqlClient.SqlConnection(My.Settings.kntnkConnectionString)
            ' コネクションを開く
            connection.Open()
            'コマンドをコネクションから作成する
            Dim command As SqlClient.SqlCommand = connection.CreateCommand
            Try
                ' #ストアドプロシージャを実行する
                With command
                    ' SQLサーバーのタイムアウト時間
                    .CommandTimeout = 60
                    ' 実行するストアドプロシージャ名を指定
                    .CommandText = "SE050_対象品番抽出"
                    ' ストアドプロシージャのパラメータを設定
                    ' commandオブジェクトのパラメータを初期化する
                    .Parameters.Clear()
                    .Parameters.Add("@UserID", SqlDbType.VarChar).Value = G_UserID
                    .Parameters.Add("ReturnValue", System.Data.SqlDbType.Int)
                    .Parameters("ReturnValue").Direction = System.Data.ParameterDirection.ReturnValue
                    ' コマンドの種類をストアドに変更
                    .CommandType = CommandType.StoredProcedure
                    ' コマンド実行
                    .ExecuteNonQuery()
                    rc = CInt(.Parameters("ReturnValue").Value)
                    Debug.WriteLine("SE050_対象品番抽出 returnValue=" & rc.ToString)
                End With
            Catch ex As Exception
                QueriesTableAdapter.InsertQuery_TK_SYSLOG("", "", "SE050K01_原材料未登録部品登録", ex.Message & vbCrLf & GetCurrentLineNumber.ToString & "行目を実行中", G_UserID)
                MsgBox(ex.Message)
            End Try
            'コネクションを閉じる
            connection.Close()
        End Using

Windows 10 Proで再起動時はシャットダウンスクリプトが動作するが、シャットダウンするとシャットダウンスクリプトが動作しない件

Windows 7 Proの時代からエンドユーザーのPCのシャットダウン時にシャットダウンスクリプトを動作させていた。しかし、Windows 10 Proに同様のことをやると再起動時は正常にシャットダウンスクリプトが動作するのに、シャットダウンを選択してWindowsをシャットダウンさせるとシャットダウンスクリプトが動作しない。

何故なのか原因を調べるためにWindows 10 Proの動作を見ていたら、7に比べて10は異様にシャットダウン時間が短いし、起動時間も短い。ひょっとしてここに原因があるのではないかと思い、[高速スタートアップを有効にする]のチェックを外したら、希望通りの動作になった。

高速スタートアップはWindows 10の終了時にメモリーやCPUの状態を保持することによってWindows 10の起動を高速化する機能である。つまり、次回の起動時も、前回終了時と同じ環境でなければならない。その為に、シャットダウンスクリプトの動作が規制されている気がする。

何にしても、新しいOSに移行すると色々と問題が発生するのは世の常である。

ネットワークの速度が遅い

ある日、インターネットからファイルをダウンロードしようとした。ファイルのサイズは50MB。直ぐに終わるかなと思ってみていたら、何とダウンロードの時間は2時間と表示された。我が目を疑ったが確かに2時間と表示されている。そういえば、ここ最近、インターネット上のホームページを見たり、ファイルを転送するのに以前に比べて時間がかかるようになっていた。たかが、50MBのファイルをダウンロードするのに2時間もかかるようでは問題なので本腰を入れて調査をしてみた。

ルーターのRTX1210のトラフィック情報(PP)を確認してみる。

PP[01] INの最大値が5Mbps～10Mbpsの間で安定している。そして、LAN1のOUTの最大値がほぼ同じ値を示している。普通こんな事はあり得ない。通常のトラフィックは波があるはずなのにこれはどうしたことか。先ずはてっとり早くLAN1に接続してあるUTPを1番ポートから順に抜いてみて変化が起きるか見てみる。1番を抜く。暫く待っても変化無し。1番を戻して2番を抜く。これまた暫く待っても変化無し。これを全ポート実施。しかし、どのポートを抜いても変化がない。これは何か特定の機器が問題の原因ではなさそうだ。

今度は、RTX1210のポートミラーリングを使ってLAN1のパケットをLAN8にも出力するように設定し、LAN8に私のPCを接続してWiresharkでパケットを解析してみる。

暫く解析を続けていると、IPアドレス:210.143.147.137、210.143.147.162に対してパケットの送受信が多い。Whoisで組織名を調べると、フリービット株式会社。日本の企業の様だ。ホームページで企業情報を見るとネットワーク関連企業だが、どうもうさん臭い。何となくコーポレートサイトという感じが希薄だ。

このフリービット株式会社が保有しているIPアドレス210.143.146.0/23をRTX1210のIPパケットフィルターで廃棄してみた。その結果がこれ。

パケットを廃棄した瞬間から、見事なまでに占有されていた帯域が開放された。この後、先程ダウンロードした50MBのファイルを再度ダウンロードしたら、僅か2分で完了した。今後は、このフリービット株式会社に対して、どのPCの何のアプリがデータを送受信していたかを調査し、最終的な対策を講じるつもりだ。ひょっとしたらデータマイニングに使われていたりして。

2019/1/25 追記
これらのIPアドレスはマイクロソフトのONEDRIVE等で使用されていることが判明した。これらのIPアドレスへのパケットを破棄するとONEDRIVEが使えなくなる。仕方がないのでまたこれらのIPアドレスとの通信を許可した。しかし、今のところ以前の様にネットワークの帯域が占有されるという現象は発生していない。

Windows XPで動作していたアプリがWindows 7やWindows 10で動作しない

Windows XPで動作していた市販パッケージをWindows 7やWindows 10にインストールした際、設定ファイルが読み込まれなくて困った。何とか解決できたのでここに記す。

　市販パッケージのHogeをWindows XP SP3で使用していた。このご時世なので取り敢えずWindows 7で動作させようと思い、Windows 7のPCにインストールをしてみた。インストール先はC:\Program Files (x86)\Hoge\

　Hogeはプログラムのインストール先フォルダー内に存在するStockEnv.iniを実行環境ファイルとして読み込み動作する。7のPCにHogeをインストールし、XPのPCからStockEnv.iniを7のPCのプログラムのインストール先フォルダー内に上書きコピーしてセットアップ完了。早速Hogeを起動してみる。StockEnv.iniに指定したDBにアクセスされずデータが0件と表示されてしまう。もう一度StockEnv.iniファイルを確認すると指定のフォルダー内に存在しているし、ファイルの内容を確認してみたが問題ない。再度Hogeを起動してみる。やはり先程と同じ。因みに、ログインユーザーは標準ユーザー。

　試しに管理者として実行してみると、正常に動作する。権限が標準ユーザーだとダメ。何故だ？？

　この後、C:\Program Files (x86)\Hoge\のアクセス権を標準ユーザーに対してフルアクセスにしたり、プログラムをXP(SP3)互換にしたり、プログラムを再インストールしたが変化無し。何故だ？？

　ここで飛び出すのがSysinternalsSuiteのProcmon.exe。Hogeを起動しProcmon.exeでHogeがアクセスしているファイルを確認。すると、C:\Program Files (x86)\Hoge\StockEnv.iniにアクセスするが、その直後にC:\Users\xxxxxxxx\AppData\Local\VirtualStore\Program Files (x86)\Hoge\StockEnv.iniにアクセスし、そのファイルを変更している。インストール先フォルダー内のStockEnv.iniではなく、ローカル・セッティングフォルダー内に作成されたStockEnv.iniをアクセスしていたのか。だから、こちらが設定した内容でプログラムが起動してくれなかったのか。納得。

　そういえば、セキュリティ強化のため、Windows VistaからProgram Filesのアクセス権が厳格化されていたっけ。管理者の場合は問題なく動作したが、標準ユーザーの権限ではProgram Filesフォルダーにファイルを作成できず、それでローカル・セッティングフォルダー内にファイルが作成されていたのか。

　XPで動作していたアプリが7や10で期待通りに動作しないときはこの辺に原因があるかも。

Windows 10にVB6アプリがインストールできない

最近購入するPCは全部Windows10。業務で使用しているアプリはWindows10対応のものもあるが、中にはWindows XP時代のまま開発が止まってしまったアプリもあり、それらは何とか動かしている。そんな中でこんなことがあった。

　VB6で開発された基幹業務のアプリをWindows10にインストールしようとしセットアップを起動したが、いつまで経っても終了しない。そのうちにアプリが異常終了しましたと表示されて終わってしまった。セットアッププログラムに対して互換性の設定などを色々と変えてみたが効果無し。このパッケージはとあるメーカーのパッケージソフトなのでソースは無いしWindows7には対応しているがWindows10はサポート外。動作しなくて当然のアプリ。そうは言ってもそのアプリが動作してくれないと困る。

　そこでいつものSysinternalsSuiteのProcmon.exeが登場。セットアップ中の動作を観察しているとC:\Windows.oldフォルダーの中を探している。ひょっとしてシステムフォルダーとしてこの中を探していて何か問題が発生しているのかも。そう思い、このC:\Windows.oldフォルダーを削除してみたら、ビンゴだった。セットアップは普通に終わった。

　C:\Windows.oldフォルダーはOSを以前のバージョンに戻すために必要なフォルダーなので、購入したばかりのPCでは以前のバージョンに戻す事は無いと判断し削除してしまった。

Windows 10 パソコン起動時にEdgeが勝手に立ち上がる

　Ｗｉｎｄｏｗｓ１０のセットアップをこなし始めた今日この頃。今日も１台セットアップ。セットアップ中はインターネットに接続可能にしていたが、このＰＣはインターネットへの接続は禁止のＰＣなので、Ｆ／Ｗでブロックをした。すると、ログオンするとなぜかEdgeが立ち上がり以下の画面が表示される。

　不思議に思いブロックされているｕｒｌを閲覧してみると

ＭＳＮ　Ｊａｐａｎが表示された。

　なぜ？？？？

　念の為、再起動しても相変わらずEdgeが勝手に立ち上がる。

　Sysinternals Suiteのautoruns.exeでマイクロソフトのアプリで悪さをしてそうなやつを順番に止めてみた。しかし、相変わらずEdgeが勝手に立ち上がってしまう。

　ネットで検索したら原因判明。
　Windows IT Centerに記載あり。
　https://docs.microsoft.com/ja-jp/windows/configuration/manage-connections-from-windows-operating-system-components-to-microsoft-services
　この頁の”13. ネットワーク接続状態インジケーター”に理由と対処方法が書いてあったので、私はグループポリシーを設定した。

　これにてログオン時にEdgeが勝手に開く件は一件落着した。とはいえ、この設定をすることでNCSI(ネットワーク接続状態インジケーター)がデバイスがインターネットと通信できるかどうかを判別しなくなるので、設定する人はそれで良いのかの判断が必要。

　しかし、この対処をするまでに４時間もの時間を費やしてしまった。

　Edgeが勝手に立ち上がるのはネットワークに接続されているときで、ログオン時にネットワークに接続されていないとEdgeは勝手に立ち上がらない。しかし、ネットワークに接続されるとEdgeが勝手に立ち上がる。

2017/10/17 追記
　危惧していた事が起こった。インターネットに接続可能なＰＣにも同じ設定を行ったところ、OneNoteで「インターネット接続がありません」と表示されてしまい、OneDriveに保存してあるOneNoteのファイルが開けなくなった。NCSIが正しく判別しなくなることで他にも影響が出るかもしれない。

Microsoft Data Access Components 2.0 セットアップが終了しない

　VB6で開発されWindows 7で使用していたアプリがWindows 10の環境で使用可能か検証をした。

　セットアップを実行すると、Microsoft Data Access Components 2.0 セットアップの画面が表示されファイルがコピーされていたが、いつまで経ってもセットアップが終了しない。この画面のまま先に進まない。ひょっとするとハングアップしたかも。

タスクマネージャーで確認してみるとこんな状況。
　ODBC Driver Configuration Program(32ビット)がCPUを半分使用している。私のPCのCPUは2コアでほぼ100%の負荷。ループしているかな。

　今回のアプリは自分で開発したものではないのでソースはなく調べるのが大変かなと思いながらも、マイクロソフトのSysinternalsSuiteに含まれているProcmon.exeで調べてみると、odbcconf.exeがレジストリのI/O処理でループしている。

Procmon.exeに表示された情報で関係していそうな情報。

18:10:26.2519258 odbcconf.exe 4564 RegOpenKey HKCR\RDSServer.DataFactory\Clsid SUCCESS Desired Access: Maximum Allowed, Granted Access: Read

許可されたアクセス(Granted Access)が読み取りのみになっている。

　odbcconf.exeに関係していそうなレジストリのキーは以下の二つ。

HKEY_CLASSES_ROOT\RDSServer.DataFactory

HKEY_CLASSES_ROOT\RDSServer.DataFactory\Clsid

これらの２つのキーに対するアクセス許可を確認すると、Administratorsグループは読み取りのみでフルコントロールは与えられていない。試しに、Administratorsグループに対してフルコントロールを与えると、その瞬間にセットアップは正常に終了した。

Procmon.exeに表示された情報で関係していそうな情報。

18:14:35.4679275 odbcconf.exe 4564 RegOpenKey HKCR\RDSServer.DataFactory\Clsid SUCCESS Desired Access: Maximum Allowed, Granted Access: Read, Write DAC

許可されたアクセス(Granted Access)にWrite DACが追加されている。

　もし、Microsoft Data Access Components 2.0 セットアップが終了しない場合は、

HKEY_CLASSES_ROOT\RDSServer.DataFactory

HKEY_CLASSES_ROOT\RDSServer.DataFactory\Clsid

の２つのアクセス許可を確認してみると良いかもしれない。いつものことですが、レジストリの変更は自己責任でお願いします。当然のことながら、該当キーを変更前にバックアップは必須です。