[Office] Outlook 365/2016/2019 變更預設收件匣

在 Outlook 2007 以前，Outlook 在使用 POP3 收信時，預設會將信件收到 Outlook.pst (個人資料夾) 裡面的收件匣。

在 Outlook 2010/2013 的時候，預設依照電子郵件信箱建立對應的 .pst 來收信，但是在建立電子郵件信箱時，可以很輕鬆地選擇 .pst 讓它仍然將信件收取到 Outlook.pst\收件匣。

隨著電子郵件普遍化，一般使用者多半有多個信箱，但通常搞不懂如何透過 Outlook 設定收件方式，所以 Outlook 365/2016/2019 新版將設定收件方式加以簡化，反而導致部分舊功能因為畫面精簡後不能在一開始建立電子郵件信箱時執行。

對於大多數人來說，不同的電子郵件信箱歸類到同一個 .pst 是很自然的事，所以不太會有需求變更預設收件匣，但 Outlook 在收發郵件時，若因為當機、收發郵件過長(執行緒鎖定) ，非常常容易造成 .pst 損壞，所以我在家裡的電腦習慣用舊的方式收信，先收到 Outlook.pst\收件匣，再用郵件規則分信，這樣發生問題時，通常只有 Outlook.pst 受損，由於信件收進來就自動使用規則分到不同 .pst 後，Outlook.pst 內本身沒甚麼信件，修復起來快，也不容易造成信件遺失。

當然，也有其他特殊需求需要變更到不同的 .pst 內收信，下面就直接說明步驟了。

1. 左上角選單：檔案 > 資訊 > 帳戶設定 > 帳戶設定

帳戶設定

2. 在 電子郵件頁籤 下方，針對每個電子郵件帳戶點選 [變更資料夾]，例如將原先的收件匣改變更到 Outlook\收件匣。

選擇收件匣

若有需要新增 .pst 或子目錄，在上面畫面右側有按鈕可點選。

這樣就完成設定了。

若須將信件設定到既存的 .pst ，例如從舊電腦拷貝過來的 .pst ，就點選資料檔頁籤進行管理。

資料檔頁籤

我個人習慣將 .pst 都放到 D 槽，這樣若是 Windows 要重灌或是帳號受損，我的 .pst 都能安好無缺，而且也便於備份管理。我個人習慣將 .pst 依照功能性區分，我同學有人會依照年份區分，依照年份區分的好處是可以每年固定燒錄 .pst ，就可以確保當 .pst 受損時，可以從光碟的備份還原。

最後來看一下這個畫面擷圖對應的 Office 版本。

Office 帳戶

點選 關於 Outlook

關於 Outlook

這是公司的 Office 365 ，若是要跟家裡個人的 Office 365 連結，例如使用家裡的 OneDrive ，就在左邊點選新增服務。若要更換帳號，可以參考前篇：

[Office] Office 365 企業授權更換

風力發電可能會造成物種滅絕，還是先別用好

我很少在部落格扯跟電腦無關的，但關於風力發電的事，我也是磚家。

我待的公司早年有做風力發電，我接觸過大小風機，主要是負責風機監測，包含發電、狀態等，所以算是專業人士，而不是所謂的環保鬥士。

在開始之前，先引用中研院這篇：

從天氣預報看發電──郭志禹的「風中奇緣」
http://research.sinica.edu.tw/offshore-windfarm-wrf/

這篇主要是在說明兩風機建造過近，會因為互相影響，可能會引響投資報酬率，不過那是投資者該考慮的，死老百姓不用考慮。

從裡面引用這段：
「風通過風機之後，風速下降超過 1 公尺(每秒)的區域，面積竟然廣達 100 平方公里左右。」

風力發電主要是靠西風帶、季風、地形風為主。

從前面看到中研院的研究，一台風機影響的就有 100 平方公里，所以北部拍照打卡聖地觀音工業區旁邊的沿岸幾十隻風機，後方一百平方公里有多大？

風速下降一公尺在海上可能還沒感覺，在陸域大概就是平均少 1/5 ~ 1/4 的風量。

風量下降代表的就是微氣候的變化，風攜帶的水分、平衡的熱量減少。當微氣候變化，就會造成物種遷移，無處可去的物種就會消失。

農委會有個計劃「推廣水田生態環境保護及地下水涵養補注」，俗稱種水。種水的理由是因為田間休耕，導致沒有正常灌溉，田間的水就沒有蒸發散，氣溫會升高，此外田間的泥鰍、青蛙等生態無法正常維持，因此針對休耕的田地仍然要灌溉，除可維持田間生態水平衡外，還可間接補注地下水。

也就是說田間只是休耕沒種水稻，就被認定為破壞生態平衡，而 100 平方公里平均風速少一公尺要維持 20 年，會不會破壞生態，會不會破壞微氣候？從海面上帶來的水氣，會因為風速降低 (風通量減少) ，導致攜帶到陸域的水氣跟著降低，對流造成的降雨量就會減少，除人類有灌溉的地區外，其他地區的水平衡會不會改變？

國中理化教大家，能量守恆。

在岸邊或是近海將風能轉換成電能傳輸到陸域，陸域居民又因為自然風減少，必須開空調，那麼實際電能需量差異不但沒減少，反而又增大了，能量轉換與傳輸，必然造成能量損失，也就是說，季風帶來的風能，若用來風力發電，不但造成水氣減少，微氣候變化，既有生態破壞，還增加空調的用電。

另一個風力發電的大戶在西風帶，也就是大家知道的歐洲這種高緯度國家。高中地理與地球科學教大家，西風帶是由地球自轉引起。

西風帶：
https://zh.wikipedia.org/wiki/%E8%A5%BF%E9%A2%A8%E5%B8%B6

國中理化教大家，能量守恆。

當西風帶的風能一部分轉換為電能後，與地球自轉平衡的能量被損耗後，地球自轉速率會不會變化？

國外有一些小眾的看法的確認為地球自轉平衡可能被破壞，大部分看法並沒否決能量被損耗，只是認為影響小可忽略。

那麼成語中積沙成塔是甚麼意思？

高中生物教大家，開花結果跟光週期有關
成花誘導：https://zh.wikipedia.org/wiki/%E8%8A%B1#成花诱导

若有關，可能導致植物無法正常開花結果，就會造成糧食危機，不是人類而已，是全球靠植物維生的大多數動物，而無法開花結果可能導致植物無法繁衍，最後連植物也會滅絕。

另外地球的洋流一般認為西風帶的風切應力有一定的影響力，導致了洋流方向：
洋流：https://zh.wikipedia.org/wiki/%E6%B4%8B%E6%B5%81

大洋經過多年的平衡，甚麼時候洋流到達，可替不同區域的海洋生物帶來食物，產生完整的食物鏈，可參考下面那篇連結。
https://zh.wikipedia.org/wiki/%E5%8A%A0%E5%88%A9%E7%A6%8F%E5%B0%BC%E4%BA%9E%E6%B4%8B%E6%B5%81

當西風帶的風能一部分轉換為電能後，推動洋流的風能就會減少，洋流的平衡也會被破壞。

所以看下來，風力發電只會破壞生態平衡，不能叫綠能，西風帶的風力發電破壞全球平衡，季風的風力發電破壞區域平衡，風力發電只適合用在不得不用的情況下。

小常識：風力發電一般在風速 1.5 m/s 開始發電，到達 15 m/s 時，自動煞車停止發電，15 m/s 就是俗稱的七級風，因此颱風來的時候，風力發電是不運作的。

[Office] Office 365 企業授權更換

我的 NB 安裝的是 MSDN Subscription 附的 Office 365 E3 ，他可以自己測試 Office 365 管理帳號與使用者帳號。我的 MSDN Subscription 是 2019/07/31 到期，但一時還沒失效，我就先等著。

今天我的 Office 365 授權終於失效，看起來是 40 天跳失效訊息，這也可以用來概估同事離職後，公司 Office 365 失效的期限。

開啟 Outlook 提示帳戶失效

Outlook 工具列提示失效

雖然上面已經跳出 Office 365訂閱發生問題的提示，但是 Outlook 仍然可以用，我想滿 40 天只是開始會提示，可能還要一陣子 (聽說是 180 天) 才會完全不能用 Office 。

所以開始要改用公司給的 Office 365 授權，因為我還沒登入過公司給的 Office 365 商務進階版授權，所以要先登入一次，修改密碼。

第一次登入企業的 Office 365 要改密碼

我原先的 Office 365 E3 帳號是 xxxx@xxxxxxt.onmicrosoft.com，公司的 Office 365 商務進階版帳號是 xxxx@xxxxxxs.onmicrosoft.com ，所以後續圖片請看 t 或 s 的尾碼來判斷是哪個帳號。

然後從 Outlook 的選單 > 檔案 > Office 帳號來變更，首先從圖上中間上方點選切換帳戶。

點選切換帳戶

會跳出一個對話框，點選下方新增帳號。

點選 新增帳戶

依照導引畫面完成。

點選 是

稍後片刻

點選 完成

現在可以看到使用者資訊已經變成公司的新帳號，但是右側產品資訊仍然是我的就帳號。

兩邊帳號不相同

點選右邊產品資訊的變更授權。

變更產品授權

點選登入，一畫面引導登入公司授權。但是重新開啟 Outlook 還是會顯示授權異常，還是上面兩邊帳號不同的圖案。

可能是公司授權沒有 Skype for Business ，登入 Office 網站下載 Office 安裝檔，採用覆蓋性安裝。

下載 Office

覆蓋性安裝完就正常了，畫面顯示還有一個授權，但預設還是顯示我的舊授權。

顯示其他授權資訊

這樣就完成 Office 365 E3 授權變更為 Office 365 商務進階版授權了。

雙授權

[追加 2019/09/26]

• 

Windows Update 後，變成兩套 Office ，只好移除一套。

[T-SQL] IIF 與 CASE WHEN … THEN … ELSE … END

有個案子現場是前面的人做的，因為距離關係，分了三區設置 4G 網路，把資料扔回 Server 。

但妙的是其中有兩區相連，比如說 A/B 區。當 A 區設備沒開，A 區的流量就要歸總到 B 區算。

本來 Server 只負責接收資料，針對這種情形，建一個分析規則表，等待現場回傳後計算。

本來是在 SQL Server 2016 上開發測試，所以 T-SQL 語法習慣就選用
https://docs.microsoft.com/zh-tw/sql/t-sql/functions/logical-functions-iif-transact-sql

IIF(bool, true_value, false_value)

但實際上要跑的資料庫是 SQL Server 2008 R2 ，沒想到 SQL Server 2008 R2 不支援 IIF 。

我記得以前微軟文件會寫相容層級，找半天都找不到，只好一版版翻，似乎是從 SQL Server 2012 以後開始支援。

只好退回舊版，改用
https://docs.microsoft.com/zh-tw/sql/t-sql/language-elements/case-transact-sql

CASE
WHEN bool1 THEN result1
WHEN bool2 THEN result2
ELSE result3
END

所以，比如說原先要用：
(IIF(Col1=Col2, ‘真’, ‘假’)) AS 判斷
改成
(CASE WHEN Col1=Col2 THEN ‘真’ ELSE ‘假’ END) AS 判斷

[SQL] 透過 Access 轉換資料庫架構

有個客戶要結束節能業務，把他們的節能服務轉交給我們公司，他們原先的雲端監測系統阿祖 (Azure) Web Server 與 SQL Server 都要關閉，要由我們的監測系統自己處理。

它們的系統是現場 IPC 沒有查詢展示介面，監測資料在現場暫存後，就上傳到雲端資料庫，所以雲端資料庫每分鐘一筆，主要的資料表架構如下，每個月一個資料表：

分區視別字串	點位識別字串	資料時間	值(字串)	原始值(字串)
長度100	最大長度50	DateTime	長度50	長度50

所以在上面這個資料表架構下，每個月大概七百萬筆資料，約佔用空間500MB。

看了對方資料架構我才知道，為何對方網頁限制每次查詢時間間隔不能超過七天，而且每次查詢起來大概要跑 3 分鐘才會出來。

我的架構分成兩部分，現場端有IPC安裝 SQL Server Express資料庫，每分鐘一筆，統計分析後上傳到雲端資料庫，不同時間間隔分開放，以小時、日、月、年為單位統計。現場資料庫考慮效能及容量，將點位抽出來列表，核心資料表則所有時間放在一起不分表，資料架構大概是：

資料時間	點位1	點位2	…	點位n	狀態
DateTime	Double	Double	…	Double	長度n

所以每月大概變為43200筆，約佔用空間 50 MB。

所以需要將資料格式進行轉換，將對方類似一維的數值表格架構轉成我的二維的數值表格架構。

首先先將對方的 Azure SQL Server 整個備份到我電腦的 SQL Server Developer，光是做這件事，我電腦硬碟就被吃掉 40 GB …

考慮到我電腦內的資料庫避免異動，確保乾淨，所以我不打算在 SQL Server 處理資料格式轉換，我打算把每個月的資料匯入到 Access 後再轉換成我要的格式。

Access 轉換的架構

查詢「刪除 data 資料」這個並不需要存在，是我開發過程期間測試 SQL 語法用的。

資料表 raw 是用來放置 SQL Server 的匯入暫存資料，資料表 data 則是樣本資料表，為了快速處理，我還是依照每個月複製貼上 Data_yyMM 資料表，進行格式轉換，最後再統一匯入一個資料表。

所以核心的程式碼很單純：

DoCmd.SetWarnings False ' 關閉告警視窗
DoCmd.RunSQL nowQuery ' 執行 SQL 語法
DoCmd.SetWarnings True ' 恢復告警視窗

所以上述部分迴圈的目的就是為了組合 SQL 語法來達成目的，所以後面說明就專注於 SQL 語法，而非 VBA 語法。

匯入資料到 raw

將 SQL Server 資料表資料匯入到 Access raw 資料表，SQL 語法如下：

INSERT INTO [raw]
SELECT 點位識別字串,資料時間,值
FROM [來源表格名] IN " [odbc; Driver=SQL Server Native Client 11.0; Server=(local); Database=資料庫; UID=帳號; PWD=密碼; ]

注意到了嗎？這邊最特別的就是 IN 子句，透過 IN 子句跨越資料庫，這功能只能在 OLEDB 資料庫驅動程式下用，所以表示 Access 內 VBA RunSQL 是跑 OLEDB 來做查詢，這部分說明沒寫，這段應該是這篇的精華。

對 In 子句延伸閱讀可在部落格右側搜尋輸入：In 子句。

插入時間

為了避免無效時間，所以先在 data 資料表內將時間插入，並可確保所有時間都不被遺漏，SQL 語法如下：

INSERT INTO [Data_yyMM]
SELECT DISTINCT 資料時間 FROM raw ORDER BY 資料時間

更新各欄資料

這邊就依據資料點位對應到資料欄位，逐欄更新，所以前一步插入時間很重要，插入時間後，就有 PK 欄可供 UPDATE 使用。逐欄迴圈 SQL 語法如下：

UPDATE [Data_yyMM]
INNER JOIN (
SELECT 資料時間, 值 FROM raw WHERE 點位識別字串="點位代碼"
) AS tabData ON ([Data_yyMM].rdate=tabData.資料時間)
SET [Data_yyMM].點位i = tabData.值

透過前一步的插入時間做為 PK 值 JOIN ，就可以整欄資料直接轉移。

刪除 Raw Data

這段 SQL 語法太簡單，應該無須解釋。

DELETE FROM raw

小結

所以就能快速透過 Access 執行巨集持續進行不同資料表的資料匯入、表格架構轉換，不過雖然有跑刪除 Raw Data ，但還是無法防止 Access 長大，因此長大到 2 GB 時， VBA 會被中斷，重新壓縮 Access 檔案，再改回圈開始處，就可以繼續往下跑。

我這時會先把 Data_yyMM 搬到其他 Access 檔案，把這個轉換用的 Access 盡量空出來跑資料轉換，不過我把 Data_yyMM 合併的 VBA 也寫再這個轉換檔，所以最後我會把所有 Data_yyMM 搬回來合併。

[SQL Server] 資料庫損毀與修復

週日傍晚異常斷電，UPS 也掛了，周一早上重開後，伺服器一直跑得不順，在事件檢視器發現資訊訊息，建議跑 DBCC CHECKDB (SQL Server 2014 的資料庫)

Info:825 建議進行資料庫檢查

另外也有錯訊息

Fail:8646 建議進行資料庫檢查

Fail:824 建議進行資料庫檢查

周一下午跑過
DBCC CHECKDB (db)

Info:8957 資料庫修復結果

，修復了 77 個錯誤。

但此之後，就頻繁發生 LOCK 錯誤

Fail:1204 無法 LOCK 資源

並且仍然會發生建議要跑 DBCC 的錯誤。

Info:825 建議進行資料庫檢查

考慮了一晚，周二早上決定建新資料庫：

1. 新建 db1 ，把 db 周日凌晨定時備份還原到 db1
2. db 更名為 db_o ，db1 更名為 db
3. 用匯入匯出精靈把 周日備份後的資料從 db_o 匯入到 db1
4. 所以 db_o 除了人為測試與自動備份外，等同無人存取

週二晚上本著廢物利用的精神，平常沒機會玩資料庫修復，跑：
DBCC CHECKDB (db_o)
多次，每次跑完，錯誤數都比前一次多 (主要為索引錯誤)

Info:8957 資料庫檢查52個錯誤

Info:8957 資料庫檢查54個錯誤

跑
DBCC CHECKDB (db_o, REPAIR_REBUILD)

Info:8957 資料庫檢查59個錯誤

無法修復

另外發生資料庫存取時間過長。

Info:833 存取超過15秒

改跑
DBCC CHECKDB (db_o, REPAIR_ALLOW_DATA_LOSS)

Info:8957 資料庫修復60個錯誤

修復了 60 個錯誤，又比上面 DBCC CHECKDB (db_o) 檢查的錯誤要多。

再跑一次：
DBCC CHECKDB (db_o, REPAIR_ALLOW_DATA_LOSS)

Info:8957 資料庫修復11個錯誤

又修復了 11 個錯誤。

早上再跑一次
DBCC CHECKDB (db_o, REPAIR_ALLOW_DATA_LOSS)

Info:8957 資料庫修復結果

終於沒錯誤了。

周二傍晚 db (原db1) 在事件檢視器有跳出資訊建議跑 DBCC CHECKDB ，但今天改跳出故障，建議跑 DBCC CHECKDB ，回頭翻了跳電前的 db_o 是有資訊事件建議跑 DBCC CHECKDB ，所以我想應該是還原時，把原先 db_o 的索引錯誤還原到 db1 ，利用午休的時間跑
DBCC CHECKDB (db, REPAIR_ALLOW_DATA_LOSS)
多次，直到沒有錯誤為止。

沒錯誤後，另外跑重建索引
DBCC DBREINDEX (DataTable)

但是晚上仍然發生建議跑 DBCC CHECKDB ，我有跑了

Info:825 建議進行資料庫檢查

DBCC CHECKDB(db)

Info:8957 資料庫檢查0個錯誤

顯示 0 個錯誤，此外上面 LOCK 錯誤訊息持續出現。

目前找不到問題來源，懷疑可能跳電時，硬碟或 RAID 控制卡有受損，因為有些問題是持續存取時間過久，這次事件就是純練功修復資料庫了。

[Book] 讀書心得 – IoT物聯網無限商機：產業概論x實務應用

IoT物聯網無限商機：產業概論x實務應用

這本書最大的好處是把可能相關的領域內容都提了一遍。

從網路上搜尋資料，通常是東一撇，西一點，很難全面的看趨勢，容易掉到自己不熟悉的領域，或是以偏概全。

當然全面看過一遍後，可以看到 IoT 雖然快速大量發展五年了，但是普及率還是有限，我自己看是還是偏貴與不習慣。

物聯網對投資者來說，必要的總體成本必須下降，比如說因投資 IoT 後，客服成本或是生產成本等，最終呈現的成本應該是要下降，才會促進投資者花錢投資。

但現階段顯然成本仍然增加，雖然增加了應用方案，效益似乎沒想像中高，所以整體環境都在想踏入，但都沒有很有效踏入。

比如說 ETC 好了，大家理想上電子收費後，因為少了一堆收費員，高速公路的收費應該僅須要維護高速公路而降低人事費，所以應該過路費要下降，但實際上電子收費相關設備與維護人力成本高昂，導致過路費沒有明顯下降，甚至有些情況是稍微漲價，那麼不管技術或是理想，就會認為是錯誤的決策，甚至有圖利廠商的疑慮。

我在1992開始念類神經網路，1996的碩士論文也是類神經網路為主，2004在西雅圖參觀 Microsoft Home ，近十年都在能源監測領域，也建置規畫過實驗性質的智慧家庭系統，除了貴以外，還有很大的穩定性問題。

IoT 除了設備多，可能故障設備數量多外 (假設故障率不變) ，大部分是商用等級設備，不耐高溫，此外最麻煩的是維護人員需要專業人員。一個感應器沒回應，一般的維修人員完全不知道是無線通訊問題還是硬體問題，此外由於大量的 IoT 設備，就有設備代號對應問題，所以發生問題後，必須專業人員處置，但專業人員有限，使用單位就無法在第一時間完成維護。

IoT 在我看來，大家還在找出路，但已經有大者恆大的趨勢，不論是優先使用的，還是優先生產的，而初期投資的生命週期通常不長，每年都在革新換代，導致中小企業無力導入，大型企業也不會全面導入。

IoT 未來到底要怎樣走不知道，但必然是大降價以後才會大躍進，短時間內，應該還是叫好不叫座。

[T-SQL] SQL認證帳號新增資料庫未正常掛入使用者

工作的資料庫其中一個資料表超過 2 億 2 千萬筆，但這個資料表常常用在 JOIN 上，導致工作日查詢網頁時，大概要拖到 20 秒以上，假日沒人用倒還好，大概 3 秒可以出來。

某個資料表超過兩億筆

這個資料表存了超過兩百個專案的資料，所以考慮採專案切割的方式，將每個專案資料切到不同資料庫，再由各專案資料庫的資料表進行 JOIN ，減少維度障礙。

超過兩百個專案進行切割，換句話說就是要建立超過兩百個資料庫，所以打算建立完整的 T-SQL 語法，方便後續使用。

正常建立的資料庫使用者如下，考慮到管理問題，預設加入 [BUILTIN\Administrators] ，再加入自行建立的 SQL 認證的 [馬賽克B] ，以下簡稱 UserB 。

資料庫的使用者

開發的時候用測試機來測 T-SQL ，使用本機 Windows 認證，所使用的 T-SQL 語法簡化如下：

USE [master]
GO
/* 建立資料庫 */
GO
USE [專案資料庫]
GO
/****** User [BUILTIN\Administrators] ******/
CREATE USER [BUILTIN\Administrators] FOR LOGIN [BUILTIN\Administrators] WITH DEFAULT_SCHEMA=[dbo]
GO
/* BUILTIN\Administrators Set db_owner */
/*
EXEC sp_addrolemember 'db_owner','BUILTIN\Administrators' /* Before MSSQL 2008r2 */
*/
ALTER ROLE [db_owner] ADD MEMBER [BUILTIN\Administrators]
GO
/* --分隔線-- */
/****** User [*******B] ******/
CREATE USER [*******B] FOR LOGIN [*******B] WITH DEFAULT_SCHEMA=[dbo]
GO
/* [*******B] Set db_owner */
ALTER ROLE [db_owner] ADD MEMBER [*******B]
GO


正常建立完成的 UserB 點選 [屬性] 可看到 [使用者名稱]、[登入名稱] 都如同 UserB 的內容，左下角的輸出畫面可以看到沒有錯誤。

正常建立的 UserB 帳號

測試完沒問題後，從我的電腦跑，變成遠端存取建立資料庫，但這一建立就發生錯誤。

遠端建立無法正常加入使用者

起初發現是 UserB 無法加入這個資料庫，但用手動也加入不了，經詳細比對後，發現是 SQL Server 自動掛入的 dbo 帳號會變成：

[使用者名稱]=dbo，但 [登入名稱] =UserB ，然後 [登入名稱] 又不給我改回 dbo ，所以無法加入 UserB，只好砍掉重練。

經過多次測試，發現上面的 T-SQL 語法從分隔線處分成兩次執行，第一次執行時，SQL Server 會正常掛入 dbo 帳號，第二次執行就可以正常掛入 UserB 帳號。

目前要得到我要的資料庫安全性登入帳號的測試結論是：

1. 本機使用 Windows 認證時，上面 T-SQL 語法可以同次執行
2. 遠端使用 SQL Server 認證時，上面的 T-SQL 語法需要從分隔線處分兩次執行

原因我還沒找到，做個心得記錄，後面可以翻查。

本機 Windows 認證我測試過 SQL Server 2008r2、2012、2014、2016、2017 都正常。

[RAID] 跳電導致 RAID1 組態異常

06/02 早上 08:07 跳電約 10 秒，除了先前我的 NB 電源供應器掛了：

[電池] 工作的 NB 電池膨脹

還有多台設備出問題，其中包含一台網頁伺服器。

周一早上上班覺得網頁伺服器反應有點慢，遠端連進去檢查。

系統碟由兩顆 512 GB SSD 採 RAID1 組成，資料碟由兩顆原廠的 2 TB SATA3 硬碟採 RAID1 組成，2 TB 硬碟平常沒啥事，就是凌晨時，跑排程把系統碟的資料庫備份出來，然後再跑排程同步資料庫到備份伺服器。

連入網頁伺服器後，桌面跳出 RAID 異常警告，登入 LSI MegaRAID 軟體後，看到四顆磁碟掛三顆，1 顆 512 GB SSD，2 個 2 TB 資料碟。

在 2 月的時候 ([RAID] 更換故障硬碟)，才因為原先 2 顆 256 GB SSD 掛一顆，我把 2 顆 256 GB SSD 分次升級到 2 顆 512 GB SSD ，才四個月，Intel 五年保固的 SSD 應該沒這麼差吧？而且 2 TB 硬碟是拿來做資料庫備份，一天一次的存取量不大，這種存取量搞不好十年都不會掛。

既然硬碟顯示故障，就分別把三顆熱拔出來，使用 HDDScan 檢查，檢查的結果都正常良好，檔案也能讀取，就只能打客服電話報修。這台伺服器當初採購時有加買五年保，故障的時間大概是三年八個月，所以還是原廠保固期，所以加買五年保固不能省，不然過三年就出狀況了。下午，華碩委外的維修商打來了解詳細情況，初步懷疑可能故障點：

1. 主機板受電力衝擊損壞
2. RAID 背板異常
3. 硬碟故障 (2 TB 為原廠硬碟，算在五年保固內)
4. RAID 組態受電力衝擊異常，可能要重新設定

周二早上廠商打電話來說，故障點 2 的 RAID 背板缺料，主機板跟硬碟準備好了，他早上跑嘉義兩案，下午來我們這。

廠商來了後，更換主機板問題沒改善，換了兩顆新硬碟，問題沒改善，只能猜測是 RAID 組態異常，RAID 組態異常必須在 LSI BIOS 重新設定，可能會造成硬碟掉資料，廠商也提了，以後買 Server 最好還是加購 RAID 卡，主機板上的 RAID 效能比較差，而且不像加購 RAID 卡都有外掛鋰電池，可以記憶 RAID 組態。

我系統碟在拆出來檢測時，已經整顆備份，2 TB 硬碟本身用於資料庫備份，又有遠端同步，所以就算被洗掉也沒關係。

然後在 LSI BIOS 測試，這狀況掛得很澈底，LSI 內因為顯示硬碟故障，所以檢測、修復都不能跑，只能把虛擬磁碟刪除，然後重新新增虛擬磁碟，設定 RAID1 ，刪除虛擬磁碟後硬碟都顯示健康，所有重新建立虛擬磁碟還滿順利的，依照原先順序新增回來。

開機很順利，自動進入 Windows ，除了被標記損壞的 SSD 自動進入 ReBuild 外，作業系統正常運作，兩顆資料碟正常存取，重組 RAID1 運氣好，完全沒有被自動格式化，需要重做。所以維修商東西收一收就走了。

不過滿特別的是，上次 256 GB 升級到 512 GB 因為我的 LSI Embedded MegaRAID 沒有擴展功能可選，所以只能當 256 GB 用，但是重建組態後，就被識別為 512 GB，就可以在 Windows 的磁碟管理做擴展，把整個 512 GB 拿來用。

周四系統碟又異常跳原先故障那顆損壞。

RAID1 自動 ReBuild

熱插拔重新插入後，又自動 ReBuild ，這次唯一沒換過的就是 RAID 背板，我有點懷疑是機房濕度高導致受潮，所以把空的熱插槽蓋拆下來，加強空調循環，看能不能改善。

隔了兩周想起來，在 06/20 登進去檢查，不知道是運氣好還是不好，進去剛好看到兩顆 2 TB 硬碟，LSI 在自動巡檢。

LSI 事件

自動巡檢中

由於顯示這 2 TB 硬碟仍處於最佳化中，就擺著沒管。

06/28 華碩打電話來做委外廠商評鑑調查，想起來再進去看，LSI 事件在 06/20 以後，只有登入紀錄，就沒發生其他事件了，暫時先當這件事結案吧。

唯一沒測試過的是 RAID 背板，該不會問題在這吧…

[iOS] 開發者帳號年費續約

去年建的開發者帳號：[iOS] 註冊一個開發者帳號

即將過期，收到 Apple 寄來的通知信：

年費續約通知信

登入網頁後，進入繳費步驟。

填入付款資訊

填入發票資訊

確認付款資訊下單

訂單完成

約 2 分鐘後可收到訂單確認通知信。

訂單確認通知信

約半個小時後可收到收據，收據不等同電子發票證明，有點類似出貨單，但裡面有電子發票號碼。

電子收據

大約七個小時後，收到電子發票。

電子發票通知

電子發票大概長下面那樣。

電子發票

[電池] 工作的 NB 電池膨脹

公司的 NB 平常插頭都插在牆孔，下班時關機，上班時開機。

週日早上 08:07 左右，公司約跳電 10 秒鐘，跳電期間的電力衝擊，衝壞了公司好些設備，包含機房三台 Server ，與一台 CCTV 專用的 PoE Switch 。

我的 NB 變壓器也被衝壞了，不過我一開始並不知道。

周一早上，到公司把 NB 開機後，先去檢視機房故障的狀況，安排好排除故障的任務後，大概 40 分鐘後，回到座位，發現 NB 關機，我是設定插電期間，永不休眠，只關螢幕，有點疑惑地按下電源開機。

電腦看起來從休眠狀況恢復，有點納悶地繼續用 3 分鐘左右，忽然斷電式關機。

再按電源開機後，看了一眼，電源指示燈正常亮著，我當時以為是變壓器的電源指示燈，約剛進 Windows 時，又斷電式關機。

之後連續兩次按電源開機，都在 Windows 進度列時，斷電式關機。

之後按電源完全沒反應，我想，也許是 NB 內置的直流變壓器掛了，因為先前誤以為電源指示燈式變壓器用的，所以完全沒猜變壓器故障。

打算拿到皇家俱樂部送修，基於資訊安全，要把硬碟拆出來，機器拆開一看，電池膨脹，或許是電池導致電力系統問題？

拆硬碟發現電池膨脹

拿到皇家俱樂部檢測時，發現插變壓器可以正常運作，但是電池已經無法充電，客服說我的變壓器可能故障。

仔細回想，的確有可能，我的電池本來就充飽電用不久，就是快掛了，若是變壓器故障，就應該是電池低電量自動休眠，持續耗用到電池低電量無法蓄電。

不過電池膨脹怕自燃，所以基於安全考量，還是留機下來更換電池。

返回公司後用電表測試變壓器，果然已經無輸出，變壓器都變成零電壓了。

晚上華碩通知，電池缺料，要從總倉庫調貨，直到周三晚上通知，05/15 ~ 06/30 間，華碩周年慶，檢測不修不收檢測費 500 ，修理享九折優惠，電池要 4,980 ，折扣後 4,482 ，週四一開門就可以取件。

NB 取回來後，裝硬碟時，順便讓新舊電池來個合照：

新舊電池比較

開機後，一直進入 BIOS ，觀察 Advanced 的 SATA 裡面有偵測到硬碟型號與序號，但是在 BOOT 區一直沒出現開機設備可選擇。

後來打華碩客服電話，叫我試試：

1. Security > Security Boot Menu > Boot Controller > Disabled
2. Boot > Launch CSM > Enabled

果然可以開機。

推測可能是我的 Win10 連續三次在開機過程中中斷，被 Win10 標記為不可使用，所以 BIOS 無法選擇用來開機，但是改用傳統 Win7 年代的方式強制讓 BIOS 允許檢測開機時，Win10 會自動進安全模式供檢修，我當時只是沒電，所以直接按繼續恢復正常開機後，等完成開機選擇關機重開，就一切正常了。

這次跳電公司不少設備故障，我去取件時，順便把兩位同事的 NB 送修，還有同事手機充電器也掛了，台電的暴衝，誰都沒輒~

[Access] 磁碟或網路錯誤

有個網站使用 Access 檔案做語言資料庫，依瀏覽器語系，使用 ASP.NET 透過 ODBC 存取資料庫。

這兩天忽然跳出 Access 錯誤，剛好用碰上 RAID1 組態錯誤，所以一直以為是檔案系統錯誤造成。

錯誤訊息如下：

Exception information:
Exception type: Exception
Exception message: ErrorMessage: ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver] 磁碟或網路錯誤。
ERROR [01000] [Microsoft][ODBC Microsoft Access Driver]一般警告 無法開啟登錄鍵 ‘Temporary (volatile) Jet DSN for process 0x14e4 Thread 0xa80 DBC 0x1bd5c5e4 Jet’。
ERROR [IM006] [Microsoft][ODBC 驅動程式管理員] 驅動程式的 SQLSetConnectAttr 失敗
ERROR [01000] [Microsoft][ODBC Microsoft Access Driver]一般警告 無法開啟登錄鍵 ‘Temporary (volatile) Jet DSN for process 0x14e4 Thread 0xa80 DBC 0x1bd5c5e4 Jet’。

JET 錯誤

RAID1 修復後，錯誤依舊。

在苦無對策下，繞道 C:\Windows\Temp 目錄看一看，忽然發現不太正常的 JETxxx.tmp ，從 1 ~ FFF 都有，共有 11280 個檔案。

JET 暫存檔案

既然不太對勁，全選刪除。

重新執行網頁，就正常了。比對擷圖來判斷，懷疑應該是部分不正常結束的 Session ，檔案沒正常刪除，留在系統暫存目錄內，而自動編號應該是限制 1 ~ FFF 間，所以自動編號爆了就沒救了。

第一次碰到這個問題，記錄下來以後可查。

[Book] 讀書心得 – 職業駭客的告白

這個月又花點時間把公司書櫃的書又看一本。

職業駭客的告白：軟體反組譯、木馬病毒與入侵翻牆竊密(暢銷回饋版)

職業駭客的告白

這本書拋去組合語言部分，實質上是一本滿不錯的入門書，介紹入門可能被攻擊的管道，C 語言也用很簡單的案例，基本上閱讀障礙很少，適合資訊管理的人員閱讀，不求看完就能防禦駭客，但至少可以評估資訊管理上的安全漏洞。

為了資安環境的考量，除了避免觸犯刑法妨害電腦使用罪外，有效降低入門的小白，我個人認為觀念可提，但是步驟宜模糊省略，省得一堆垃圾流量跟垃圾軟體在流竄，作者出書的時候，細節都跳過，我覺得很棒，當然也有可能是編輯砍掉也不一定，至少這本書沒有說些讓人容易犯錯誤的內容，我是滿喜歡的。

當然也不是沒有槽點，小吐槽的地方是 2015 成稿，2018/11 出版的書幹嘛還用 VS2010 … 中間至少有 VS2012/2013/2015 吧… 不過我想可能是案例中的虛擬機是 WinXP ，VS2010 是最後一版能開發 WinXP 可用軟體的開發環境，所以不能算槽點。

最大的問題應該是閱讀體驗不太好。

這本書裡面有很多程式碼範例，但幾乎都是螢幕擷圖，還很多用記事本擷圖，更扯的是四頁長的程式碼，就用記事本翻頁擷四張圖，這該是有多愛記事本啊。這就造成印成書的字很小，大概只有正常文字的四分之一，又因為擷圖應該是有 ClearType 的問題，字型有自動去鋸齒，也就是字緣模糊灰階化，所以有點不清楚。

另外我猜測可能是為了同時出電子書，從博客來看到電子書不到 3 MB，可能拿給印刷廠交印的電子檔是 pdf 格式，輸出 pdf 格式時，圖片沒有特別調高解析度，造成圖片採用 jpeg 壓縮在 pdf 內，字就更模糊破碎了。

再加上是圖片印出，本身不是純黑色，而是灰色字，書本紙質又會反光，有輕微老花眼的我根本看不清楚內容。所以到最後，凡是關於程式碼擷圖的部分我幾乎都快速跳過。

這本書如果要再版，最好針對閱讀體驗做改善，除了少量為了表示用軟體編譯的有圖有真相部分外，程式碼或是螢幕輸出的反組譯之類的內容，還是複製出來用區塊文字方式呈現，才能正確清楚的閱讀。

[Excel]白做工了，規劃求解與 VBA

很久沒有做分析了，都在 code …

上個月老闆交代我做個分析，想來想去，想要最佳化還是用數學規劃，線性規劃是個快速解決問題的方法，只要問題不複雜，直接用線性規劃求解就可以了。

問題是離開學校後，沒有好的軟體可以算線性規劃，想起來還有 Excel 的規劃求解可以用，就翻開 Excel 玩。

話說 2005 年在新加坡 MVP亞洲年會中，跟當時負責中文化的洪士吉老師與這個巨集的澳洲原作者聊過，當時聽洪士吉老師有原始碼跟密碼，我那時自己也用 VBScript 寫一個線性規劃的 ASP 線上網頁，所以主要討論的是卡曼卡法的加速解跟 Lindo，但是我論文不是搞這方向，離開學校後就甩到邊邊角角了。

我平常為了加速 Excel 開啟，所有的增益集都關閉，Office 2003 年代短暫的玩過規劃求解，但主要還是玩 Lindo ，開啟規劃求解增益集後，發覺設定方式完全不一樣了，看了一下線上手冊，上面寫 Excel 2010 後改成這樣，只好重新學習。

首先，先把自己寫的線性規劃翻出來，用相同的模型建構 Excel ，自己會比較容易上手：

線性規劃命題範例

按下 [進行最佳化分析] 後，可得到計算結果：

線性規劃計算結果

這個命題是在做教材範例，假定一個有閘門的滯洪池或水庫，在已知預報進水量下，受到滯洪池蓄洪量、放水路放水等限制，目標是穩定洩水減低洪害，各限制式的依據參閱上面網頁擷圖右側文字說明。

下面是我喜歡的規劃求解表格樣式，規劃求解仍然使用 Excel 公式，所以並沒有需要排得整整齊齊，但是為了人類容易閱讀，還是排成表格方式比較不會錯，詳細個位置說明，放到最後，先看操作步驟：

在 Sheet 上建立規劃求解命題

從 選單 點選 [資料] > [規劃求解] ，逐項設定：

規劃求解設定

規劃求解計算約 1 秒內可完成：

規劃求解完成

計算結果與設定對話盒連結註記說明：

規劃求解計算完成

1. 圖上數字對應到 [規劃求解參數] 對話盒的數字，並不對應到這邊說明的項次。
2. 變數名我選擇放在第一列，C1 ~ J1 ，這種架構大家都容易看得懂。
3. 變數計算結果我選擇放在第二列，C2 ~ J2，預設可以不輸入，參見前面建立命題的圖，不輸入，就代表起始解為 {0} 集合。
4. 目標函數的係數我放在 C3 ~ J3，也就是 MIN C。
5. 限制式左側的係數我放在 C4 ~ J19 ，不等號我放在 M4 ~ M19，常數項我放在 N4 ~ N19。
6. 最佳化可以在 [規劃求解參數] 輸入 Excel 公式，但這樣會造成每次設定的複雜化，比如說目標函數一變，或是限制式調整時， [規劃求解參數] 的設定就要跟著變，所以為了方便起見，建議像我這樣做，在 K3 輸入陣列公式，讓係數乘變數，就可以降低 [規劃求解參數] 的設定問題，K3 正確設定完成後，複製到 K4 ~ K19 ，讓限制式的係數一樣可以乘變數。注意，陣列公式輸入完成後，要按下 {Shift}+{Ctrl}+{Enter} 三個鍵，才能正確變成陣列公式。
7. 最後在 [規劃求解參數] 對話盒 [載入/儲存] 按鈕，點下 [儲存] ，選擇 N2 。

這個計算結果，可以透過 K/L/M 三欄檢查限制式是否成立，或是直接觀看 N 欄，限制式成立的邏輯公式就是使用 K/L/M 三欄。

在說明項目 6 中，使用了陣列公式，實務上會增加計算量，也就是係數 0 x 變數，但卻可以讓設定參數簡易許多，就如同本例。

做到這，可以發現 L 欄用不到，因為在 [規劃求解參數] 對話盒 [新增] 限制式時，都要手動輸入，我的目的是要解決老闆交付的任務，所以針對此命題範例建立了測試的 VBA 程式碼，細節到正式命題再修改：

用 VBA 建立規劃求解參數

為了方便起見，我在 VBA 內直接建立陣列公式，也就是說上面建立規劃求解的途中，K 欄不用輸入，其他 [規劃求解參數] 對話盒的輸入，都用 VBA 自動產生。

規劃求解不支援直接輸入不等式，所以用 GetRelationIndex 函數將不等式轉成索引值輸入。

如果不想自己打太多程式碼，可以用錄製的再進行修改，不過這張圖上的程式碼已經很精簡了，錄製會很亂，不如直接打，再改欄位值即可。

規劃求解的函數使用說明參考微軟官方網址：https://docs.microsoft.com/zh-tw/office/vba/excel/concepts/functions/using-the-solver-vba-functions

好了，終於開始建立正式命題，先把正式命題縮小為一天24小時的時資料進行連續量分析，建個小小的模型，測試看看是不是能正常運作：

規劃求解超過上限

不得不爆粗口…

「規劃求解限定為 200 個變數儲存格和 100 個限制式，加上變數儲存格的限值。」

100 個限制式？這個規格限制下，根本是玩具吧… 規劃求解，我只好繼續把你放生了…

[2019/06/05]

花了點時間，把網頁版 ASP 的 VBScript 轉成 VBNET 語法，順便把命題轉成類別，測試還算成功。

VBNET WinForm 輸入命題

輸入完線性規劃命題後，點選 [限制式] 頁籤 下方工具列那個圖示 (測試程式沒有管 Icon 的美觀度) ，即可得到輸出結果，輸出改用 StringBuilder 產生 HTML 語法用 WebBrowser Control 輸出，這樣之後若有需要，可以在工具列放預覽列印的按鈕，呼叫 WebBrowser Control 的預覽列印。

VBNET WinForm 輸出結果

不過裡面還有一些 Bug ，大型命題解不出來，這就造成除錯困難，大概還要加一頁來輸出線性規劃各步驟階段的計算表格，才好除錯。

[iOS] 更新到 macOS 10.14 開不了機

話說昨天我 NB 更新 Win10 1903 ，看到旁邊的 MacBook Pro 閒閒的，想到半年沒開機，就打開來讓他自動更新。

先更新了一堆 App ，macOS 10.13.x 更新了 3 個版本，並多次自動重新開機。

更新完後，在 AppStore 上顯示 XCode 最新版要安裝 macOS 10.14 ，就從 AppStore 順手更新到 10.14 。

都在更新 OS ，我是更新小王子呢…

更新完 10.14 ，然後自動重開機就變成下面照片那樣關機或重試一直循環。
錯誤訊息為：

無法開機的錯誤畫面

A critical software update is required for your Mac, but an error was encountered while installing this update.
Your Mac can’t be used until this update is installed.

試過 Try Again 不成功，又試了 Shut Down 後開機，仍然是這個畫面。

把錯誤訊息丟到 Google 搜尋看看，倒是有不少人碰到。

這個影片是重試幾遍就正常了：

A critical software update is required for your Mac – Problem Apple Powerbook Pro

這兩個網址是說可能要重裝：

A Critical Software Update Is Required for Your Mac, but an Error Was Encountered While Installing This Update

How to fix the critical software update problem on Macs

想說等今天空下來再處理，下午忙完後，打開 MacBook Pro 電源，過了 5 分鐘想起來，轉頭看向 MacBook Pro …

居然自己好了…

正常開機到新版

我在懷疑可能是昨天連續更新約 15 GB 後過熱造成機器不正常，所以放冷到今天開機後就正常了… 來繼續更新 XCode 6.1 GB 吧~

[WU] 升級 Windows 10 1903 雜記

昨天到 MSDN Subscription 下載 Win10 1903，並安裝。

Win10 1903 跟 1809 一樣，分成 商用版 跟 客戶版，商用版有企業版沒有家用版，客戶版則有家用版沒有企業版，兩個版本都有專業版跟教育版，不過 1903 也要用 DVD R DL 燒。

1903 x64 企業版我安裝近 3.5 小時，跟 1809 一樣，安裝完會複寫註冊資訊，所以一些圖檔軟體也會被改回預設值，會觸發部分軟體自動重新安裝。

安裝好後，發現開始工具列卡了很大的搜尋工具列，真是礙眼…

下方出現搜尋工具列

習慣舊畫面，還是關掉這個畫面。

關掉搜尋工具列比較習慣

升級完後，自動跑的安全性更新 KB4495666 更新三次都失敗，改手動下載更新三次也失敗 (約 100 MB) ，看到這篇說這個更新還有問題，所以乾脆暫停更新 35 天，下個月再看看情況。

https://support.microsoft.com/zh-tw/help/4495666/windows-10-update-kb4495666

這幾天若是有碰到問題再來更新這篇。

[2019/05/22 更新]

今天更新 KB4495666 仍然出錯，如下圖。改手動更新 KB4495666 之後出的更新後，再跑檢查更新就沒東西需要更新了，KB4495666 更新上不去的，可以改用手動更新。

透過手動更新就不用再安裝 KB4495666

[AI] 讀書心得-圖解人工智慧 從零開始了解人工智慧的原理與應用

上個月，看到同事在看公司書櫃的書：

圖解人工智慧 從零開始了解人工智慧的原理與應用

人工智慧除了偶爾看到新聞或是論文有瞄一下外，好久沒有完整的閱讀了。趁春假借來看看，看完寫篇讀書心得。

圖解人工智慧 從零開始了解人工智慧的原理與應用

我是從1992年開始接觸類神經網路。([AI] 關於類神經網路的學習經驗分享)

當初看的應該是倚天的這本：

暢談類神經網路

1994年到電機所修習詹寶珠教授碩博合開的類神經網路。1996以類神經網路分析計算撰寫碩士論文「分佈型類神經網路降雨逕流模式之研究」。

從我的角度來看，這本相當於我當時看上面那本暢談類神經網路，對於完全不在這個領域的，有一個入門的理解，讓人大概知道甚麼是人工智慧(這本重點只在類神經網路)。推薦給一般想要入門的人員看。但不推薦給研發部門主管或是有實作過任何一個類神經網路的人員看。

這本書的有一些小缺點：

1. 人工智慧不僅限於類神經網路，雖然類神經網路是主流
2. 因為作者是日本人，整本書很偏日本現況介紹
3. 讓讀者對類神經網路會有過度幻想

這本書大概讓我了解目前類神經網路的主流是卷積神經網路 (Convolutional Neural Network, CNN) 與循環神經網路 (Recurrent Neural Network, RNN) ，Google、Microsoft、IBM 有提供 API 可以試用或購買服務，nVidia 的 GPU 能力很強大。

對於熟悉類神經網路的從業人員來說，這些資訊很容易取得，不需要花時間閱讀。

至於研發部門的主管，看這本可能會對人工智慧過度樂觀，錯估開發成本與時程，錯估預期成果，因此不推薦。

但對於完全不懂類神經網路的，或是不懂人工智慧是甚麼的，倒不失為入門讀物，特別是高三要大學入學面試的、畢業生要求職的，不妨讀讀看，或許面試時考官會隨便問，至少有個觀念可回答。

好久沒有完整閱讀一本書，感覺還不錯，接下來打算把公司書櫃的書一個月掃一本。

[VS] Visual Studio 2019 @ Windows 2012 R2 無法正常安裝

昨天正常安裝 VS2019@Win10 x64 後，今天打算在 Win2012r2 上安裝。晚上選完安裝內容後，跑去睡覺，早上一看，發現卡在 Microsoft.Net.4.7.2.FullRedist 上：

VS2019 安裝失敗

點選「查看已驗證的解決方案」，沒啥有幫助的文章。

有其他人卡在 .Net framework 4.7.2 無法安裝

打開工作管理員，發現是執行下面執行檔失敗：

C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.Net.4.7.2.FullRedist,version=4.7.3062.2\dotNetFxLatest-x86-x64-AllOS-ENU.exe

拷貝到 VS2019 安裝目錄後，本著「關掉引擎好換檔」的心態，先重新開機，再手動安裝 .Net framework 4.7.2 試看看。

手動安裝 .Net framework 4.7.2

沒想到還是失敗，但是手動安裝的好處就是有畫面。

.Net framework 4.7.2 安裝失敗

從記錄檔可以看到錯誤原因發生在安裝 Windows8.1-KB4054566-x64.cab 時，找不到物件或內容。最重要的是有錯誤訊息。 (failed with 0x80092004)

安裝的詳細錯誤訊息

一開始我以為是 VS2019 封包的檔案有問題，到微軟下載中心抓最新的 .Net framework 4.7.2 (NDP472-KB4054530-x86-x64-AllOS-ENU.exe) ，執行安裝，仍然發生上面錯誤訊息，比對內容檔案，是同樣的時間，所以應該沒更新的可以搞。

想說開啟新增移除程式看看，一看，居然 .Net framework 4.7 以後都沒有：

Net framework 沒有 4.7 以後版本

想說那就從 .Net framework 4.7 逐步安裝好了，沒想到裝 4.7 與 4.7.1 都說我已安裝更高版本的 .Net framework ，那我就試試看安裝 4.7.2 的繁體中文語言套件 (NDP472-KB4054530-x86-x64-AllOS-CHT.exe) ，還是回應找不到物件或內容。

想來只能想辦法移除 .Net framework 4.7.2 重新安裝，就 Google 搜尋移除 .Net framework 4.7.2 的文章，結果找到一篇很有用的文章：

.NET Framework 4.7.2 install error 0x80092004 — Cannot find object or property

看標題似乎就是中獎了~ 裡面內容概要是說在 TechNet 論壇有位 mwjvl 網友幫助他解決這個問題。解決步驟如下：

1. 建立一個存放 kb 的目錄，目錄名不是很重要，但是為了方便解說操作，用下面的目錄名：
   C:\updatefix\expanded\
2. 到微軟 Windows Update Catalog 下載 KB4340558 存放到：
   C:\updatefix\
3. 將所有下載的 .msu 解壓縮到
   C:\updatefix\expanded\
   ，使用指令：
   expand -f:* “C:\updatefix*.msu" C:\updatefix\expanded\
4. 使用指令將 C:\updatefix\expanded\ 內的所有 .cab 安裝到 Windows 內，其中 WSUSCAN.cab 不用安裝，視情況可能需重新開機。使用指令：
   dism /online /add-package /packagepath:C:\updatefix\expanded\filename.cab
5. 若發生錯誤，移除重新安裝。使用指令：
   dism /online /remove-package /packagepath:C:\updatefix\expanded\filename.cab
6. 重複步驟 4 ，直到所有 cab 都成功安裝。
7. 上面建立的 C:\updatefix\ 沒用了，可以刪除
8. 可以重新安裝 .Net framework 4.7.2 了

在步驟 2 ，我下載 KB4340558 時，有 3 個 .msu 可下載：

KB4340558 有三個檔案可下載

在步驟 4 ，我在安裝 KB4338419 時，發生 0x80092004 錯誤，我把它移除重裝。

發生錯誤移除重裝

完成後，手動安裝 .Net framework 4.7.2 ，就成功安裝了。

成功安裝 .Net framework 4.7.2

安裝完要求我重新開機：

重新開機啦

重新開機後，再執行 VS2019 安裝，選「重試」，就會跳過 .Net framework 4.7.2 ，進行下一個功能安裝：

繼續安裝 VS2019

終於安裝完成，要求我重新開機：

VS2019 要求重新開機

確認安裝完成，從安裝精靈第一次啟動 VS2019：

第一次啟動 VS2019

總算搞定收工。不過詭異的是，我的 Win2012r2 在「程式和功能」那邊還是沒有任何 .Net framework 4.7 的安裝，只有 Visual Studio 2019 的安裝。

[VSCode] 1.32 便攜版的語言介面未正確升級

便攜版就是免安裝版。

Visual Studio Code 強大之處就是小巧方便，所以我當然不會自作孽去安裝安裝版，而是使用免安裝版。

我在多台電腦上有安裝 VSCode ，上次在公司 NB 升級 1.32.1 時，有發現繁中語言介面升級後不正常，所以我採用整個目錄砍掉重裝，但發現這樣我得把外掛也跟著重裝，所以家裡電腦升級 VSCode 時，就改變方案，沒想到在家裡已經是 1.32.3 了，我公司升級應該是五天內的事，沒想到五天內改了兩個版本。

VSCode 升級通知

事先我是知道要升級，但是我習慣用便攜版，所以我不從對話框升級，而是到官網下載壓縮檔後解壓縮，覆蓋舊的便攜版。

先前舊版升級時，覆蓋完就正常結束了，沒想到低於 1.32 版升級到 1.32.1 或 1.32.3 版，都會呈現介面中英文混雜的情形。

呈現中英文混雜的介面

改善的方法很簡單，先移除舊版中文介面。這邊很弔詭的是，VSCode 版本是 1.32.3 ，但是中文介面的版本是 1.32.4 。

移除繁體中文介面

再點選 [install] 安裝繁體中文介面。

安裝繁體中文介面

安裝完語言介面並不會立刻變更，把 VSCode 關閉重新打開，就會顯示新的繁體中文介面了。

恢復成為繁體中文介面

難得碰上不正常升級，我在想，可能是語言的翻譯檔標籤變更之類，導致不正常吧。

[Android] 編譯給手機與上傳 Google Play – Xamarin for VS2017

話說，兩年前雖然完成開發 Google Play 的 App ，但因為去年在弄 Apple Store 的 App ，使用 Xamarin for Mac ，所以我已經完全忘了如何上傳 Google Play ，為了自己不知道多久後可能還會再上傳，還是自己留個紀錄。

編譯跟封存的步驟參考前一篇：

[Android] 無法正確封存 App – Xamarin for VS2017

這篇直接繼續封存開始。封存時的畫面如下：

編譯後封存中

正常完成封存後，畫面右下角可以選散發。在很舊版的 Android 模擬器，這時可以不選散發，直接將封存完成的 apk 拿到模擬器上測試，但目前的版本是不行的，所以一定要選 [散發]。

封存後選散發

點選 [散發] 後，若是要直接給手機或模擬器用，選 [臨機操作] ，要是要作為正式版上傳 Google Play ，選 [Google Play] 。事實上選 [臨機操作] 的仍可人工上傳到 Google Play ，此外，點選 [Google Play] 的話，只能發布正式版、測試版，不能進行封測，我記得兩年前我在用的時候，應該沒有 [Google Play] 這選項，應該是後來微軟加入，方便開發者上傳用，但以版本管理而言，我個人偏好 [臨機操作] ，這可確保封存的 apk 檔案時間是自己可以掌握的，手上的備份版本與 Google Play 一致，當然影響不大，只是個人偏好而已。

散發通道

A. 臨機操作

選取 [臨機操作] 後，要選一個來簽署身分識別，比如說你是用個人名義開發軟體還是用公司名義，或是集團公司可能有很多分公司，原則上這個檔案應該另外保存，如果有另外保存，例如公司共用的身分識別檔案 .keystore，第一次選 [匯入] ，如果從來沒建立過，第一次選 [+] 建立一個新的。建立時可以選擇有效期限，我是建議選長點時間，因為要更新軟體要用同一個身分識別上傳，建立身分識別後，要上傳 Google 取得對應的憑證，這個在網路上找一下，我兩年前做的，我也忘了步驟了，反正這篇重點不在這。

簽署身分識別

選擇 [另存新檔] 後，會讓你輸入密碼，必須記得第一次建立時輸入的密碼，否則無法正確簽署身分識別。這裡另存新檔的好處是你能掌握簽署身分識別後的檔案，不像直接上傳 Google Play 的，完全不知道暫存在哪。

輸入身分識別密碼

回到 Visual Studio 2017 ，可以看到正在產生簽署身分識別後的 apk 檔案。

散發身分識別寫入中

完成後，就可以傳輸到手機安裝，像一般沒有開 Google Play 帳號的 App ，就是把完成後的檔案放在網站上供人下載安裝。由於 Google Play 會對 App 進行檢查，一般來說，還是放上 Google Play 比較令人信賴，至於電視盒那種涉及侵權的軟體，就只能放上網頁供人下載了。

B. 上傳 Google Play

上傳 Google Play 可以把上面完成簽署身分識別的 apk 手動上傳到 Google Play ，也可以讓 Visual Studio 自動上傳，在上面散發通道選擇 [Google Play] 按鈕。

一樣，上傳 Google Play 也要簽署身分識別，不過可以從圖上分辨出是要為了臨機操作還是給 Google Play 使用。

散發到GooglePlay

密碼輸入的部分就跳過了，這邊由於不選擇存檔位置，所以簽署身分識別後的檔案 VS2017 不會自動幫你保存，如果又碰上 VS2017 的佛性發揮，一切隨緣時，上傳 Google Play 的 App 可能會變得不能安裝執行。

第一次上傳 Google Play 時，要輸入代理帳號：

註冊Google帳號

由於我以前都是人工手動上傳，所以要建立一個新的。選擇步驟 1 的超連結，可在 Google 開發網站註冊一個 OAuth 認證帳號。

建立 Google API OAuth 帳密

在資安的觀念上，不要在非官方的登入口輸入你原始的帳號密碼，即使是 VS2017 ，也不能輸入原始帳密，所以建立一個專用的帳密來登入，這樣也有好處，要是原始帳密進行密碼定期變更，VS2017 的自動登入不用變更，當發現帳密疑似外洩時，把這組帳密從 Google 刪除即可。

可以直接從網頁上複製帳密貼到 VS2017 的對話框，考慮到可能得重灌電腦或是 Visual Studio ，最好還是下載 JSON 保存，未來找帳密比較方便，當然也可以到網頁上查詢。

輸入 Google API OAuth 帳密

如果已經在 VS2017 註冊過 Google Play 帳戶，上面建立帳號的步驟就可以跳過，當然，如果說開發的軟體有分個人跟公司的話，就點選 [+] 再輸入個人帳號資料即可，有分的話，名稱一定要分出來才好辨識，沒有的話就直接點帳號與 [繼續] 進行下一步。

選取 Google API 帳號

由於我要發布正式版，所以選擇生產環境。

GooglePlay 上傳選擇

我的目標 API 設為 Android 4.4 (19)，在臨機操作不受影響，仍然可以安裝，但是 Google Play 則不接受，被踢掉，錯誤訊息為：

上傳 ‘com.[公司].[軟體]’ 時發生錯誤: Your app currently targets API level 19 and must target at least API level 26. [403]

VS2017 API 版本過低

我懷疑是不是 VS2017 限制，改用手動上傳，確認為是 Google Play 限制，必須改版。Google Play 錯誤訊息則為中文：

上傳失敗
你的應用程式目前的目標 API 等級是 19，但最低目標 API 等級必須為 26，才能確保應用程式採用最新的 API，讓安全性與執行效能達到最佳狀態。請將最低目標 API 等級調整為 26。

Google Play API 版本過低

只好將最低目標調整為 Android 8.0(26) ，先做臨機操作，經過測試，Android 4.4 / 7.0 / 8.0 都還能安裝，就重新編譯上傳。

VS2017 上傳 Google Play 中

上傳完成後，登入 Google Play Console 檢查上傳狀態，可以看到上傳完成就自動發佈，從 Console 到商店更新大概還要 15 分鐘左右，要看商店是否已更新要稍微耐心等候。畫面上一個尚未發佈的版本，是我先前測試 API 19 的版本，再擷圖時尚未刪除，後來已經刪除了。

網頁檢查上傳結果

在 Google Play 商店會顯示目前版本的修改內容，所以最好人工進行編輯，避免使用者對於改版原因產生困惑。

編輯版本修改資訊

好了，自己把步驟都記錄下來，希望下次要用的時候，操作方式不變… 不然又要到處上網找如何做了。