VB.NET CSVファイルをデータテーブルに読み込む方法について検証

業務上必要に迫られて今回3つの方法を検証したが、結果的にはMicrosoft.VisualBasic.FileIO.TextFieldParserに軍配が上がった。

方法1)
System.IO.StreamReaderクラスでレコードを1行ずつ読み込み、読み込んだレコードをSystem.String.Splitメソッドを使ってカンマでセパレートし、データテーブルに格納する。
結果)
ダブルクォーテーション中に在るカンマを区切り文字として認識してしまい、一つの文字列が2つの文字列に分けられてしまう現象が発生。でも、実数は正しく読み込まれた。また、コードが多く可読性が低い。

方法2)
OleDbConnectionクラスとOleDbDataAdapterクラスを使い、データテーブルに格納する。
結果)
文字列は正しく読み込まれたが、実数の小数点以下が読み込まれない現象が発生。予めデータテーブルにフィールドを追加しておき、そのフィールドのデータ型にDECIMALを指定しておいても変わらなかった。コードは少なく可読性が高い。

方法3)Microsoft.VisualBasic.FileIO.TextFieldParserクラスと同クラスReadFieldsメソッドを使い、データテーブルに格納する。
結果)
文字列も実数も正しく読み込まれた。コードは少なく可読性が高い。

番外編)
この他にもネットには方法が存在していた。スピードを求めるならば、既存のクラスを使用するのではなく、自力で解析コードを書くことみたいだ。

番外編 しゃべるねこ、しおちゃん

下手な説明は必要ありません。見てもらえば分かります。とても可愛い。可愛すぎる。最高だ!!
http://www.youtube.com/watch?v=hJYlXaFdp0o&hl=ja&gl=JP&warned=True&client=mv-google

Windows7 x64 環境に於けるVB.NET WebBrowser PDFインライン表示

.NET FRAMEWORK 3.5で開発したアプリがWindows7 x64環境で正しく動作しなかった。

実装した機能
WebBrowserコントロールにpdfファイルをインライン表示する機能

現象
x64環境だと、インライン表示されず、別窓に開いてしまう。つまり、pdfファイルをダブルクリックした時と同じ画面。

解決方法
VSのコンパイラの詳細設定で、ターゲットCPUをAnyCPUからx86に変更(因みに、x64では駄目だった。adobe readerは32ビットだからね。)。

これだけで解決してしまった。

でも、この解決方法を見つけるまでは、実にまる1日かかった。
ネットで検索しても解決方法は見つからず、仕方がないのでadobe のSDKを使ってOLEでPDFを表示することにしたのだけど、WebBrowserよりも動作が遅い。何故か分からないけどpdfのページ数が多いと極端に遅い。しかし、仕方がないのでこれで我慢しようかと思っていた時、ふと気付いた。SDKのサンプルをx64環境で動作させる時、AnyCPUだと動作しなかったのでx86に変更してコンパイルして動作させた。ひょっとして、WebBrowserも同じかと思って試してみたところ、案の定、動作した。

あ～、今日はこれで仕事は終わりにしよう。気分上々。

SQL文て意外と奥が深いんだな

業務用アプリでデータチェック処理が2分かかっていた。俺の感覚では数秒で終わらないといけない処理なので、早くなる様にアルゴリズムを変更したら逆に5分かかるようになってしまった。

そこで、今度はSQL文のWHEREを重点的に見直した。
今まで文字列を=で正確に比較していた部分を、LIKE %で曖昧検索にしたらそれで処理速度が向上。更に、いくつかの条件式を一つの条件式に纏めてみたら(単純に纏めたのではないよ。ほぼ同じ条件になる様に全く別な条件式に変えた。)これで劇的に向上。その他細かいチューニングをして、最終的には2秒で終わるようになった。

う～ん、まだまだ勉強が必要だな。

ADO.NETでExcelブックのデータ取り込み

開発中の業務用アプリで、Excelブックからデータを取り込みたいのだが、JET OLE DB プロバイダーを使って読み込むと、取りこぼしが発生することが判明。

マイクロソフトの技術資料によると、「従来のデータベースとは異なり、Excel テーブルの列に直接データ型を指定する方法はありません。OLE DB プロバイダが列内の 8 行をスキャンして、そのフィールドのデータ型を推測します。」とある。

例えば、ある列でデータの先頭から8行目までは空白セルが続き、その後に数値が入っているセルが出現すると(例えば9行目)、その数値が無視されてしまう。つまり、空白セルと同じ扱いになってしまう。

試行錯誤した結果、書式に数値を指定しておけば、推測の結果が数値となり、そのデータは正しく取り込まれることが分かった。

推測に使用する行数は拡張プロパティのMAXSCANROWSを指定する事により、最大で16行まで指定できるが、1～16行目迄は空白で、17行目に1が入っていると17行目は空白になってしまう。

一番の解決策は、Excelテーブルの列に直接データ型を指定出来る事なのに、マイクロソフトは何故そう出来るようにしてくれないのだろう。

結局、VBA(Visual Basic for Applications)でマクロを作って、それをVB.NET側から起動する事にしたのだが、そのVBAマクロがアドインだと、VB.NET側から起動する事が出来ない。回避策はマイクロソフトが公開しているが、それについての動作は保証していない。これで業務ソフトを作らなければならないなんて。。。

まったく、何でこんな不便な仕組みを作っているんだろう、マイクロソフトは。

MS Removal Tool(詐欺プログ​ラム)に注意!!

うちの会社の1台のPCがMS Removal Toolに感染した。ウイルスバスター・ビジネス・セキュリティ、利用ユーザーの権限はPowerUser、Windows Software Update Serviceで更新と対策はしっかりとしていたのにだ。

現象は、MS Removal Toolのウインドウが表示され続けて仕事にならないそうだ。消しても消してもこの画面が表示され続ける。

ネットで情報を収集してみたら詐欺プログラムであることが分かり少し安心した。OSがXPだったのでシステムの復元で感染前の状態に復元したらMS Removal Toolは消えた。

感染経路は不明。感染したPCをその日使用していた2人から事情を訊いたが、二人ともいつもと違う画面が出たり、変な画面が出た事は記憶に無いとのこと。二人が閲覧したのはYAHOOのホームページとWiKipedia、Q&Aのホームページだそうだ。

Internet Explorerの履歴を頼りに同じ行動をしてみたが再現しない(普通の人は再現確認をしないように)。どこから感染したのだろう。

今日になって感染したPCの使用者からウイルスバスター・ビジネス・セキュリティが動いていないと報告が有り、該当PCを調査したら、確かに動いていない。恐らく、MS Removal Toolがセキュリティソフトをアンインストールしたのだと思い、再度インストールしたら正常に動作した。

何ともやっかいな詐欺プログラムだった。

全社電話網再構築

昨日、KDDIの営業課長が来社し、我が社の電話網の事を褒めてくれた。

彼の話では、これだけ大規模な電話システム構築は栃木県内では我が社が初めてとのこと。ホンダや日産でもここまではやっていないと言われた。その為、大変貴重な経験をする事が出来て感謝していますと言われてしまった。今後は、我が社での経験を他社への提案時に生かしていきたいと言っていた。

確かに、電話システムの立ち上げなんて簡単だと思っていたら、意外や意外、決めることが多く、チェックの量も半端ではなかった。稼働後も問題点が50以上発生し、それをKDDI、日本通信工販と相談しながら妥協できる部分は妥協しながら、但し、譲れない部分は何とかしてとお願いして、ほぼ当初考えていた通りのシステムに近いものが完成した。いくつか要となる部分で業者からは出来ないと言われたけど、やってくれなきゃ困ると言ってお願いしたら、結局具現化出来たものな。業者は大変だったと思うよ。

今回の目的の一つ、電話の利便性は確実に向上したと思う。もう一つの目的の通信費の削減。これは、4月分の請求書を見てから判断したい。でも、まだ途中経過を見ただけだけど、通信費は確実にそして大幅に減少していた。