投稿

ラベル(VBA)が付いた投稿を表示しています

Translate

MicrosoftはExcelのVBAを終了させに掛かっているかもしれないと思う理由

イメージ
VBSを非推奨アナウンスはVBAも視野に入れたアナウンスなのかもしれない 先月の11月位から、Excelのアップデート毎に、割と複雑な処理を持っているExcelのVBAにて、今まで通りの正常処理が行えないトラブルが増えている。 Onedriveが起因するトラブルは度々起きているが、それ以外のトラブルも増えてきた。 そういえば昨年の10月から、VBS(Visual Basic Script)が非推奨となった。 レガシーVBの生き残りは、後はVBAのみとなった。 しかし、VBAは、Excelではおまけでついているような機能だとして、ACCESSではVBAでの実装がほぼメインであり、こちらまで非推奨になる事は無いとは思いたいが、そもそもレガシーVBを今から習得する若者も、市場シェア的には随分減ってきている。 最近のEXCELでのVBAの挙動がおかしくなる件は、EXCELマクロをMicrosoftが終了させてがっているのかもしれない。 最近は、自動化ツールでの代用や、Asteria、Dataspiderといったノーコード、ローコードを代わりに使用する現場も増えている。 Excelマクロを使用する理由は今や、ITに予算を掛けたくない企業と、個人の為にだけある機能となってきているのかもしれない。 VBAだけを軸にやっていこうと考えている人は、少しだけ軸の調整も検討した方が良さそうだ。 TIOBE INDEXでも示している通り、コードで実装するならシェアが増加中のC#を選択するのが良いのは一目瞭然だが、ノーコード、ローコードを組み合わせるのもマクロ処理の代わりとなるので、Excel以外でのデータ処理も視野にそちらに軸をずらすとどちらの案件も拾っていけそうではある。

Excel-VBAのADOでデータベーステーブルの内容をForを使わずに一括する転記する方法

イメージ
Recordsetの内容をFor分で回さずにシートへ反映する 例:ACCESSファイルのテーブル情報を取得して一括でEXCELへ反映させる 使用するACCESSファイルには下記のような商品マスターテーブルがある これをExcelのVBAからADOでデータ取得し、下記のように用せずに一括で反映させる。 使用するADOのバージョンは迷いがちだが、今ではすっかりOFFICE365のExcelを使用している企業が殆なので、古いバージョンの事は余程配慮が必要でなければ、【Microsoft ActiveX Data Object 6.1 Library】を選択すれば良いだろう。 稀に、32ビット版をまだ使用している場合は【Microsoft ActiveX Data Object 2.8 Library】を使用する事になる。 SQLでデータを取得し、Excelのワークシートへ一括反映させるコードのサンプルは下記となる。 Dim sql_con As New ADODB.Connection Dim sql_rs As New ADODB.Recordset sql_con.Open "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=P:\OneDrive\Download\test\test.accdb" Set sql_rs = sql_con.Execute("SELECT * FROM 商品マスター") Range("A1").CopyFromRecordset Data:=sql_rs sql_rs.Close sql_con.Close Set sql_rs = Nothing Set sql_con = Nothing Rangeが持つCopyFromRecordsetメソッドで、指定したセルから、一括で表形式でデータベースから取得した内容を反映させる事が出来る。 EXCELのVBAでデータベースを取得してか

VBAやVBでWithを使うのは避けた方が良い

Withを使うと、非同期処理や他コードへの移植に支障が出る。 オブジェクト変数または With ブロック変数が設定されていません VBAで、処理速度改善等で、最終的にはApplication.Ontime 等を利用した非同期処理に手を出す事になるが、コーディングにWithを利用していると非常に不味い事になる。 非同期処理でSheet1とSheet2の両方に何かを出力するプログラムがあるとして、Sheet1への非同期処理と、Sheet2の非同期処理が同時に動いた際に、With Sheets("Sheet1")= "test"とWith Sheets("Sheet2") という処理が同時に動作すると、 片方のWithはSheet1を指しながら、同時にSheet2のセルへ何かを書き込む処理が在ったとすると、Sheet1へ書き込まれるべきものが、Sheet2の.Range("A1").Value = "1" とみなされSheet2へ書き込まれたり等してしまう。 両方の処理でWithがSheetを指している場合は、誤動作レベルで済むが、Withがそれぞれ、別のコントロールや、共通のメソッドを持っていない物で使用されていると、「オブジェクト変数または With ブロック変数が設定されていません」と表示されてしまう。 コーディングに熟練した人であれば、予め非同期や多言語移植も考えて、Withが便利であっても使用せずにコーディングするのだが、VBAの小、中級プログラマーは、非同期や、多言語間への移植など考慮せずにコーディングするので、予めコーディング規約などで、Withは使用しない事等を規約に入れていくと良いだろう

EXCEL-VBAでやってはいけない処理速度改善方法

イメージ
配列化しても処理速度が落ちてしまう実装方法 折角配列化して処理速度改善を行っても、処理速度が改善しなくなる処理 図のように、配列化しても、データ取得の特定のデータに行きつく為に、アクセスを判別する処理が、毎回必要とする処理を実装してしまうと処理速度が大幅に落ちてしまう事がある。 データベースのようにインデックス化されたデータベースから引用する場合には問題ないが、Excelシートの情報をそのまま配列化した場合に、データベースのようなアクセス方法で実装してしまうと、処理速度の改善がされない場合がある。 何故なら、特定のデータにアクセスする為に、毎回全件データを走査していく必要があるからだ。 Excelシート情報を配列化した処理で、処理速度改善を実現する方法とは? 何も事前処理されていないExcelシートの情報をそのまま配列化して、特定の加工を施し、データを転記する場合、加工の為に配列化された情報か特定のデータに辿り着くまで毎回アクセスする必要が出てしまい、この特定のデータに辿り着く振る舞いを、1万件、2万件のデータで行うと、少量では気が付きにくかった処理時のオーバーヘッドが積み上げられ、非常に遅くなってしまう結果となる。 処理に必要なデータ順に並び替え、特定のキーが変わったら(キーブレイク)したら、次種類のデータとなったと判別するようにすると、データアクセスの度に全件アクセスを行う必要が無くなり、処理速度がかなり改善される。 配列化されたデータアクセスの処理改善まとめ 処理の度に、毎回全件データアクセスを必要とする構造を廃止し、処理が必要な順にデータを並び替え、データの上から順に一巡するだけで処理が完結する構造とすると、処理速度が随分改善する。 数十分単位だったものが、数秒で終わるケースもこれまでに経験しており、処理を便利に高機能にしたいと走ってしまった場合、大量のデータに遭遇した場合、処理速度の問題にぶつかるであろう前に、ユーザーエクスペリエンスを優先させるかを事前によく検討した方が良いと思われる事案の一件を紹介しました。

Excel VBA クリップボードを使用しないコピー方法

イメージ
通常のコピーを使用しないセルのコピー方法 Copyを使用しないセル値のコピーや転記を行う方法 EXCELのVBA(マクロ)でクリップボードを使用した実装を行うと、マクロ実行中に他の作業で、コピー&ペースト等を行うと正しく動かなくなる場合がある。 もう一度マクロを実行し直すか、マクロ実行中は操作を控えるかの選択となるが、マクロを使用するユーザーが、マクロ作成者であれば回避も可能だが、そうではない他のユーザーが利用する場合、意図しない動作をしてしまう場合がある。 セルのコピーは、Copyメソッドを利用しない転記方法もある為、今回はクリップボードを使用しない方法で、セルの範囲をコピーする方法を紹介 この方法は、クリップボードが使用されてしまう。 Range("B3:D7").Copy Range("B10:Z13").PasteSpecial Paste:=xlPasteAll 実行結果 Value(XLRangeValueXmlSpreadsheet)を使用すると、クリップボードは使用されない Range("B10:D13").Value(xlRangeValueXMLSpreadsheet) = Range("B3:D7").Value(xlRangeValueXMLSpreadsheet) 実行結果 実際にクリップボードの使用、不使用を確認したい場合は、メモ帳などで、文字をコピー後、マクロを実行し、メモ帳で、貼り付け(ペースト)を行って、コピーした文字が貼り付けば、クリップボードが使用されているかいないかが確認出来る。 クリップボードの使用をマクロで実行している場合、貼付け時に、マクロでコピーした内容が貼り付けられたり、コピーしたクリップボードの内容がクリアーされている事が分かる。

VBSでマクロの実行時に警告を非表示にする方法

イメージ
マクロ付きExcelファイルを実行する際に、VBScriptで警告を抑制する方法 VBScriptでマクロ付きExcelファイルを起動する際に、マクロの実行警告を表示させないコード 下図のようなメッセージだけ表示するマクロ付きExcelファイルがあるとする。 何の害も無いこのマクロ付きExcelファイルのxlsmファイルを開こうとした場合でも、警告が表示される。 このファイルを開こうとすると・・・ マクロ付きExcelファイルを実行する為の警告メッセージで、「セキュリティの警告:マクロが無効にされました。」と表示され、【コンテンツの有効化】ボタンを押さなければ、マクロが実行出来ない状態となる。 確実にそのファイルが安全だと分かっており、頻繁に開くファイルであった場合には、いちいちボタンを押下する作業が煩わしくなる。 また、マクロ付きExcelファイルである、xslmファイルを自動実行するバッチ処理であったりする場合等は、人がこのボタンを押さないといけない状態だと、無人での自動化の妨げとなる。 このメッセージを抑制、非表示とし、VBScriptで実行する場合は、下記のようなコードで実現できる。 仮に、AutoMacro.vbsとして保存 Dim objExcel Dim objBook Set objExcel = CreateObject("Excel.Application") 'イベント抑制 objExcel.EnableEvents = False set objBook = objExcel.Workbooks.Open("P:\OneDrive\Download\test\testbook.xlsm")) objBook.Close() objExcel.Quit() Set objBook = Nothing Set objExcel = Nothing 共有フォルダーからコピーしてきたファイルは、あらかじめファイルのプロパティで、セキュリティに別途チェックを入れておく必要がある事をお忘れなく。

EXCELのVBA高速化対応 | データが多く遅いと感じたら

イメージ
ExcelのVBA高速化の3要素 1.一括でデータを読み取る(データ取得でForは使わない) データ取得時に下記のように、セルの範囲のデータを取得する際に、For分で回しながら一つづつ値を取得をしている場合、Excelオブジェクトは内部で様々な処理(検証や、変換等)が行われる為、それを、セル一つづつの単位で回すと、データ量が少ない場合は対して問題にならないが、データ量が増えてくると分単位でかかる場合がある。 この表を下の枠に写す悪いコード例 実行前 実行後 Sub もっさり動作コード() Dim iRow As Long Dim iCol As Long For iRow = 2 To 4 For iCol = 2 To 5 Sheet1.Cells(iRow + 4, iCol).Value = Sheet1.Cells(iRow, iCol) Next Next End Sub 高速化後 Sub 高速化コード() Dim iRow As Long Dim iCol As Long Dim OutputLayout() As Variant '一括でデータを取得し OutputLayout = Sheet1.Range(Cells(2, 2), Cells(4, 4)) '一括でデータを出力 Sheet1.Range("B6:D8").Value = OutputLayout End Sub 2.自動計算機能のOFF EXCELシートのセル内に、沢山の数式が埋め込まれている場合、シートの複製や、値をセットした際に、毎回式が評価され、自動的に再計算されてしまいます。 データが大量になってくると、この評価にものすごく時間が掛かってしまう為、OFFにすると良いでしょう。 Sub 処理() Dim iRow As Long Dim iCol As Long

ACCESSでバーコードをスキャンして登録更新する簡単なサンプル

イメージ
ACCESSでバーコード値等をスキャンや入力して、テーブルに登録、検索、更新する方法。 テーブルの内容 Bar = バーコード値等 FillingDate = スキャンした日付 (登録ボタンを押した日付) フォーム テーブルのBar値に登録が無い場合、フォームに入力された値と、今日の日付を登録 フォームに入力された値を、テーブルのFillingDateから検索し、登録された日付を表示 フォームに入力された値を、テーブルのFillingDateから検索し、FillingDateにボタンが押された日付で更新 ソース aOption Compare Database '① Start ------------------------------------------------------------------- Private Sub Button1_Click()     If Bar1.Value = "" Or IsNull(Bar1.Value) Then         MsgBox "入力してください。"         Exit Sub     End If     Dim sql_con As New ADODB.Connection     Dim sql_rs As New ADODB.Recordset     Dim sql_cmd As New ADODB.Command     Dim sql_prm As New ADODB.Parameter               Set sql_con = CurrentProject.Connection     '既存チェック     Dim sql As String          sql = ""     sql = "SELECT COUNT(*) FROM [Data] WHERE Bar = :Bar1"     sql_cmd.CommandText = sql     Set sql_prm = sql_cmd.CreateParamete

ACCESSのフォームで、ヘッダーと明細フォーム(サブフォーム)をVBA無しで紐づける方法

イメージ
ACCESSビギナー向け・フォーム、サブフォームの紐づけ方法 ACCESSでフォームのヘッダーと明細を紐づける方法 データーベース初心者がACCESSの操作に慣れ始めたころ、次に直面するのが、複数のテーブルを使って、フォーム内でデータを紐づける方法になるだろう VBAプログラムのSQLで全解決する方法もあるけれど、折角アクセスを使っているので、ACCESSの機能で紐づける方法を説明 下記のような売上ヘッダーテーブル、明細テーブルがある前提で説明。 売上ヘッダー  売上明細 売上ヘッダーと明細は、売上番号、種別で紐づけられる前提で、最初に作成するフォームは、ヘッダー側で、売上ヘッダーと紐づくフォームを用意する。 テキストボックスは、ヘッダーと、明細が紐づいている事が分かりやすいように、売上番号と割り当てておく。 もう一つフォーム作成の画面を開き、もう一つのフォームは、売上明細テーブルと紐づけし、フォーム名を売上明細として保存する。 それぞれのテキストボックスは、明細の中から表示したい内容を割り当てる事になるが、今回は、売上番号が連動している事を分かりやすくする為に、敢えて売上明細にも売上番号のテキストボックスを用意している。 また、売上明細の[既定のビュー]は、帳票フォームとしておいた方が、今回の売上入力画面で見やすい画面になるだろう。 次に、最初に作成したフォーム側で、サブフォームのコントロールを配置する。 サブフォームウィザードでは、テーブルからでも、フォームからでもどちらからでも紐づけしたい子のデータを選択しても良いが、今回は、売上明細を先に保存して作ったので、フォームから売上明細フォームを選択。 サブフォームのリンク親フィールド編集画面を表示し、親フィールドと子フィールドにそれぞれ、売上番号、種別と割り当てを行う。 すると、売上ヘッダーのフォームを一度閉じ、開きなおすと売上入力画面が表示され、最初のレコードは、売上番号1と、次のレコードボタンを押すと、売上番号2と紐づけられている事が確認出来る。 こうすれば、わざわざ、VBAでヘッダーと明細をデータを取得するSQLを作ってデータを取得して表示するとかしなくても、簡単に紐づけが可能である。 実際は、商品コー

ACCESSのVBAを実行するとACCESSが強制終了する事がある

イメージ
ACCESSのVBAを実行すると、ACCESSが強制終了する事がある ACCESSのVBAを実行すると強制終了 DoCmd.OpenQuery を疑え ACCESSのVBAを実行するといくつかACCESS自体が突然強制終了する事がある。 基本的にエラーがあれば、デバッグするか、終了するかを確認するダイアログが表示される筈だが、中にはエラーも表示されず、ACCESS自体が突然強制終了する事があるケースについて確認個所を紹介。 ACCESSが強制終了する事があるVBAのマクロの組み方は、Win APIを利用する時など起こりやすいけれど、中には、複雑なVBAのコードを組んでいないにも関わらずエラーも出ず、音も無く強制終了するパターンがある。 まずは、その個所は大抵の場合 DoCmd.OpenQuery で、ACCESSに作成しているクエリーを実行する時である場合がある為、そこにブレークポイントを張って、強制終了している箇所がそこであるか確認を行う。 強制終了している箇所が、  DoCmd.OpenQuery  だった場合は、クエリーの中身を確認する。 ACCESSのクエリーも、EXCELみたいな関数が使えるのだが、特に InStrRev関数とMID関数を使っている 場合に起きやすい。 もしも、InStrRev関数の検索文字に記号のような物を利用している場合には(㈱、№ 等の環境依存文字)、これを違うものに変更してみて実行してみよう もう一つは、InStrRev関数とMID関数の組み合わせで、InStrRev関数で検索した文字位置から、 MID関数で指定した文字だけ取得するような計算ロジックを入れたりしている場合 、InStrRevで検索対象にヒットしない、つまり 成立しない偽のデータが存在していないか確認 しよう。 その場合、クエリー側を修正するか、データ側を修正すると改善する場合がある。 こういった場合は、 大抵の場合、クエリーの設計に問題があると考えるのが適切なので、そもそも成立せず、関数エラーになるような組み方を改善させる と、ACCESSの強制終了が無くなる場合がある。

ACCESSのVBAでリストビュー(ListView)を使う為の設定 | Office365

イメージ
ACCESSでListView(リストビュー)コントロールを使う   標準のコントロールにはListView(リストビュー)は無い ACCESSでフォームをデザインする場合には、リストビュー(ListView)に変わる、表型のフォームをサブフォームとして使うことで賄えてしまう為、わざわざListViewを利用する機会も少ないのだけれども、ListViewでデザインする必要がある場合には、最初にコントロールの参照設定が必要である。 ACCESSのリボン.コントロールから、上図のようなボタンを押下する。 ACTIVEXコントロールを選択する。 参照設定から[Microsoft ListView Control, version 6.0]を選択すると、フォームのデザイン画面にコントロールが貼り付けされる。 VBAでリストビューを使う時は、注意が必要だ。 インテリセンスを使ってコーディングをする時代だが、捨て去られるVBA(VB6系)プログラムのリストビューは、インテリセンスに候補が表示されないメソッドが殆どだ。 コードのサンプル       With Me!ListView                  .ColumnHeaders.Clear         .ListItems.Clear         .View = lvwReport         .FullRowSelect = True         .GridLines = True                                    With .ColumnHeaders             .Add , , "商品コード"             .Add , , "商品名"             .Add , , "在庫数"         End With              .ColumnHeaders(2).Width = 3000          Dim itm As ListItem          Set itm = ListView.ListItems.Add(, , "1000000")     it

ACCESSA-VBA | DLookupでテーブルから特定の値を取得する方法

イメージ
ACCESSのDLookup関数でテーブルから特定の値を取得する方法 1.DLookup関数でテーブルやクエリ内を検索して値を取得する方法 概要 DLookup関数は、ACCESS固有の関数で、テーブルやクエリーからデータを検索して取得する為の関数。 ExcelにもLookup関数があるが、使い方が違うだけで機能自体はほぼ同じで、検索対象から検索文字にヒットした検索結果を取得出来る。 ExcelのLookupと違うところは、検索条件がもう少し細かく指定出来る。 メリット・デメリット メリット SQLを書かなくても簡単にデータが取得できる。 テーブルからだけじゃなく、もう少し条件を絞ったクエリーからもデータが取得できる。 完全一致だけじゃなく、あいまい検索も可能 デメリット DLookupは、ACCESS専用の関数である為、EXCELのVBAでもコードを再利用したい場合は、EXCELのマクロでも利用できるように書き直す必要がある。 使い方 Private Sub btnSearch_Click() Dim CommodityCode As String Dim CommodityName As String CommodityCode = DLookup("[商品コード]", "[商品マスター]", "[商品名] LIKE '*" & txtCommodity.Value & "*'") -1 CommodityName = DLookup("[商品名]", "[商品マスター]", "[商品コード] = '" & CommodityCode & "'") -2 Dim ITM As ListItem Set ITM = lvView.ListItems.Add(, , CommodityCod

VBAのADOで「パラメーターが少なすぎます。xを指定してください。」と表示された場合の原因

イメージ
ADODBで「パラメーターが少なすぎます。xを指定してください。」が表示される原因。 ADODB.ParameterとADODB.CommandのParameterで更新する時に出る。 .NET系のプログラマーは、データベース更新系のCommandと同じノリでやってしまうのだけれども、VBAの場合、些細なミスで頻繁に「パラメーターが少なすぎます。xを指定してください。」みたいなエラーが表示される。 主な原因は.... SQLの誤り バインド変数の数がSQLで指定しているパラメーターより実際に相違している。 Parameterに追加する際のデータ型が相違している。 エラーの内容と推測しにくいのが、3番目のParameterに追加する際のデータ型が相違しているの分だ。 エラー内容的には、SQLのバインド変数のパラメーター名が誤っているとか、パラメーターの数がズレてしまったとかを内容的には探すのだけれども、どれも問題が無い場合、3番目のデータ型が要注意だ。 しかもやっかいな事に、デバッグで2回実行すると何故か成功する等、振る舞いが不安定なので、余計原因を抑えるのに混乱する。 例えば、ACCESSのデータ型は、大きい数値、数値みたいなデータ型があって、とりあえず、何でもまかなえそうな[BigInt]を指定したりしていると、このエラーが表示される。 Set sql_prm = sql_cmd.CreateParameter("項目名", adBigInt, adParamInput) sql_cmd.Parameters.Append sql_prm アクセスのデータ型で数値は、Numericになるので要注意。 Set sql_prm = sql_cmd.CreateParameter("項目名", adNumeric , adParamInput) sql_cmd.Parameters.Append sql_prm このエラーに遭遇している人で解決が上手くいっていない人は、大抵の場合、エラー内容

ACCESSのVBAでADOを利用したバインド変数を利用したデータベース連携方法

イメージ
ACCESSのVBAでバインド変数の利用方法 | 備忘録 今のACCESSのADOは、.NETとほぼほぼ手順が同じ。 参照設定は、[ Microsoft ActiveX Data Objects 6.1 Library ] 色々な言語をやると、久しぶりにACCESSで、しかもレガシーなVB6系であるVBAをやると、色々忘却している。 今回は、バリバリVBAをメインに使ったシステムを作るので、ADOでバインド変数を利用したデータベース連携のサンプルを載せてみる。 データ取得の例 Dim sql_con As New ADODB.Connection Dim sql_rs As New ADODB.Recordset Dim sql_cmd As New ADODB.Command Dim sql_prm As New ADODB.Parameter Set sql_con = CurrentProject.Connection 'sql_con.Open Dim rs As Object sql_cmd.ActiveConnection = sql_con sql_cmd.CommandText = "select * from test where test = ?" Set sql_prm = sql_cmd.CreateParameter("test", adBSTR, adParamInput) sql_cmd.Parameters.Append sql_prm sql_cmd.Parameters("test").Value = "aa" Set sql_rs = sql_cmd.Execute MsgBox sql_rs.Fields(1) データ取得もデータ挿入も全く同じ。 ’ Ins

RPAブームで、VBAの需要も急増中 | VBA rising popularity by RPA in here Japan..

イメージ
RPAブームで、VBAの需要も急増中 あちこちの企業で、RPA(ロボティクス・プロセス・オートメーション)が流行っている。 それに乗じてVBAの需要も増えている為、各企業はVBAの人員を確保するのにも躍起になっている。 RPAとは RPAの読み方はアールピーエーと言い、簡単に説明すると、パソコンの操作を自動化する為のシステム。 もっともポピュラーなRPAは、人が操作する内容を録画して覚えさせ、後は再生ボタンを押すと一連の操作をひたすらこなしてくれるのだ。 ただ単に、人の操作した内容を録画しただけだと、全く同じ条件、同じ作業しか出来ないので、もちろん録画した操作内容を編集して、条件に応じて分岐させる事も可能。 昨今の日本企業は、政府が景気が良いと言うのとは異なり、全く逆で、ひたすら低迷しており、システムの刷新する費用もまともに払えない企業が増えてきており、不便なままなシステムを従業員が利用する事がたたある。 そんな時、このRPAは特に威力を発揮する。 不便で手間のかかり、手順が多い作業も間違いなく自動でこなしてくれるからだ。 <実際は、人がRPAを組む以上、間違いもあるのだけれども> しかも人よりもスピーディーに! ところで、これに乗じて、各企業では、VBAの需要も高まっている。 VBAとは Visual Basic for Applicarionsの略で日本では エクセルのマクロ という言い方を良くする。 これは、実際はプログラミングになる。 企業のパソコンにはほぼ確実に、Microsoft社のOffice製品がインストールされており、Excel、Wordが用意されている。 わざわざ開発環境を別途用意することなく、ExcelやAccess等(Wordでマクロはあまり需要が無い)があれば開発出来てしまうのだ。 VBAの使われ方もRPAと似ていて、基本的には業務の自動化となる。 人気言語全体( Tiobe-Index参照 )としてもは、需要が少なく見えるのだけれども、企業が必要とする言語としては、どの企業でもほぼ確実に使われている言語と言える。 何故VBAの需要が増えているのか RPAが使われるシーンの多くは、多くの場合事務的なルーチンワー

Windowsアップデートで、JET4.0の動作不良 Error in Windows update KB4041681

原因は、Oct.10.2017に配信された、Windowsアップデートによるもの。 Jet4.0はMicrosoft Accessでは、MDBにアクセスする為に使用される標準機能。 Windows UpdateのKB4041681を適用後、EXCELのVBAでJET4.0を使用して、XLSのファイルに接続しようとすると、ドライバーエラーが表示される。 かなり古いもので、サポートも切れていると思われるこのJETのバージョンで、Windowsアップデート後に発生したこの事象を、不具合と呼ぶのか、ただ、対応が遅れている企業の自業自得と呼ぶのか・・・ Jet4.0で接続して、しかも、Xlsタイプのファイルと言う組み合わせは、かなり、対応が出遅れていると思うけれど。 通常は、ライフサイクルを考えて、システムのリプレイスを見定めると思うのだけれども、止まって困るまでRunningみたいな考え方が、日本人には多すぎるな。。 先進国で一番ITリテラシーが低いと言われるだけの事はある。。。 システムリプレイスのサイクルを、システムが止まるまでと考えているエンジニアが意外と多い現れなのかも知れない。 VBA使いすぎも、Officeのバージョンに左右され過ぎて危険だと思うのだけれども・・・ もういい加減VB6からは、縁を切りたいのだけれども、、このプロジェクトはあと少しだから、何とか無難にやり過ごそう。