排除'Microsoft.ACE.OLEDB.12.0' 提供者並未登錄於本機電腦上的問題

最近處理個VB.NET的專案，他使用.ACCDB的檔案來做儲存資料庫，執行失敗使用Debug Mode時Console 有"'Microsoft.ACE.OLEDB.12.0' 提供者並未登錄於本機電腦上"的警示訊息。

看起來是缺少了Microsoft Access database engine的套件，下載32-Bit版本安裝彈了底下的訊息，看來因為安裝的Office是64 bit所以不給裝；改下載64-bit版本後可順利安裝，但異常依舊在。

這篇文章裡面提供了可以排除警示順利安裝下去的方式，備忘嚕!! 有段時間沒寫AP了，這部分經驗記憶慢慢磨滅，花了點時間排除這問題。

步驟: 從命令提示字元下去執行accessdatabaseengine.exe /quiet 就可以避開警示完成安裝。

後記:

執行EXE若環境切換到VM下，會出現0x80004005異常~從ODBC driver會發現無法load odbcji32.dll，後來發現這篇有說明原因~果然微軟的文件答案還是比較準些，所以依照Resolution的建議安裝Microsoft Acc3ess Runtime後順利排除了!!

Cause

Click-to-Run installations of Office run in an isolated virtual environment on the local operating system. Some applications outside Office may not be aware of where to look for the installation in the isolated environment.

gson.JsonSyntaxException Failed parsing SQL Date

發現WAS LOG有Gson解析JSON處理DATE有異常，爬了下文多篇文章表示程式碼未異動情況下，在不同的伺服器運行的結果會不一樣，開發環境使用TOMCAT所以測不到異常? 但WEBSPHERE報錯ㄌ...

不過LOG中顯然"九月"被Decode成"????"是屬於編碼問題，所以除了格式外Charset也要處理。

LOG: has Exception：com.google.gson.JsonSyntaxException: Failed parsing '???? 22, 2024' as SQL Date

解法備忘:

在寫入BLOB時，先指定DATE FORMAT跟Charset

Gson gson = new GsonBuilder().setDateFormat("MMM dd, yyyy").create();
byte[] bdata = gson.toJson(Class()).getBytes("utf-8");

還原時，也要設定DATE FORMAT跟Charset

Gson gson = new GsonBuilder().setDateFormat("MMM dd, yyyy").create();
gson.fromJson(new String(bdata, Charset.forName("utf-8")), XXX.class);

Logback 轉 Log4j2 套用備忘(JAVA 8)

嘗試這把專案Logback 改 Log4j2來處理日誌問題，備忘如下:

POM.xml

add

   src\log4j2.properties

                <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.23.1</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.23.1</version>
</dependency>

remove 

    src\logback.xml

                <!-- https://mvnrepository.com/artifact/ch.qos.logback/logback-core --> 
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.3.14</version>
</dependency>

試了好多篇文章的方法，底下這個最單純(可能也是若干文章匹配的是特定的版本造成的)
reference: https://howtodoinjava.com/log4j2/log4j2-properties-example/

小記: 原先處理的動力是因為從WAS環境(WIN)轉容器Docker(LINUX)，發現Docker上系統LOG檔要提供外部去檢視的資料夾都沒法順利取得，所以改方式來寫LOG看看能不能解決，不過嘗試迄今還沒成功 Orz...

SBOM 檔產製

資訊系統也要健檢了?  項目涵蓋這麼多(如下)...

裡面一個相對陌生的專有名詞是SBOM檔 參考日誌 爬了些文發現近期挺夯的，實作了下跑完sbom-tool-win-x64.exe會出現下方圖示

sbom-tool-win-x64.exe generate -b SBOM產製路徑 -bc 專案位置 -ps 供應商名稱 -pn 專案名稱 -pv 版次 -nsb 前綴網址

同時在指定資料夾會產製，看起來manifest.spdx.json就是所謂的SBOM嚕!!

Chrome/Edge的JavaScript onKeyDown(), ondblclice()事件異常

 最近一些在Chrome/Edge運行已久的邏輯被USER反映說功能異常(怪怪)，或時好時壞。

輸入時JavaScript keydown(), keyup()事件失效 參考

在<SELECT></SELECT>使用MULTIPLE後雙擊滑鼠ondblclice()會無法觸發帶入所選項。參考

恩恩...不能說邏輯不更新就不會出事，這兩種個案通報當下都覺得不可思議，爬了爬文這兩篇看來最符合預期，留存下~~後續解法也配合文章提供的方法順利排除!!

將onKeyup()至換成下面的方式來處理，原來的地方class增加ordkeyin來做識別，用迴圈主要是幫助跳下一個位置時多個class的繼承

var allInputSelector = ":input:visible:enabled";
let elementsArray = document.querySelectorAll(".ordkeyin");
elementsArray.forEach(function(elem) {
elem.addEventListener('keyup', function (event) {
    if (event.keyCode == 13) {

                       //ENTER提交
mathod_go(event);
} else if ($("#" + this.id).val().length == 8) {

                       //滿8碼跳下一個位置
$(allInputSelector + ":eq(" + ($(allInputSelector).index($(this)) + 3) + ")").focus();
event.preventDefault();
}
    });
});

雙擊問題ondblclick="mathod_go()"改成底下的方式，移除ondblclice="..." 後在class裡面增加dbRigclk做識別，識別碼選用以不重複即可。

document.querySelector(".dbRigclk").addEventListener('dblclick', function (event) {
var clickedOption = event.target;
if (clickedOption.tagName === 'OPTION') {
        clickedOption.selected = true;
}
mathod_go();   
    });

SimpleDateFormat 12-31 加1年的異常

日前USER反映12/31的資料產出異常，從系統日誌來看當天是2023-12-31但記錄上都看到2024-12-31，所以當然資料產出異常原因就是檢索的日期2024-12-31沒相對應的記錄 XD

本以為是伺服器時區設定的問題，但比對其他執行的JOB有些正常有些有同樣的狀況，故伺服器時區出錯的假設看來不成立。這時候請教GOOGLE大神看來還是免不了，爬到這篇網誌 後看來是解迷了，系統取日期的方法確實與此篇描述相同，調整寫法把YYYY改成yyyy來避開ISO 8601規則，冀望來年別再採坑了。

後記: 其他同事系統也有發現類似狀況(+1 Year)，與他分享時也表示為相同原因，看來這個坑踩的不冤，不過這段Code要打太極也能說委外廠商寫的，驗收時沒問題...就是此潛藏的異常要被察覺不容易罷了!! 經一事長一智是職場職務邁向更PRO的歷練，備忘囉!!