在  Global.asax 中, 定義了 Application_PreSendRequestContent 的話, 會影響到 Application_Error 的輸出, 即始 Application_PreSendRequestContent 是空的: 感覺像是 Application_Error 失效



 


若是沒有 Application_PreSendRequestContent 的情況下. 結果如下圖:

  


 

以下這個可以用在 global.asax 中, 但若是執行到了 aspx 就無效了.
        HttpContext.Current.Response.Headers.Add("Content-Type", "application/json; charset=utf-8");

在 aspx.cs 中, 指定 ContentType 要用以下的方式
        Response.ContentType = "application/json; charset=utf-8";

https://dotblogs.com.tw/jerrywang0109/2017/04/16/164223

SQL恢復[正在還原]資料庫

-- 切換資料庫的狀態為：ONLINE。

RESTORE DATABASE [資料庫名稱]
WITH RECOVERY
GO

VS 2013 發生的錯誤

https://stackoverflow.com/questions/23893497/no-editoroptiondefinition-export-found-error

1. Close Visual Studio
2. Open the folder: %LocalAppData%\Microsoft\VisualStudio\12.0\ (in C:\users\'%userName%'\AppData\Local\Microsoft\VisualStudio\12.0\)
3. Rename the ComponentModelCache folder
4. Restart Visual Studio.

 

錯誤訊息：
WebForms UnobtrusiveValidationMode 需要 'jquery' 的 ScriptResourceMapping。請加入 ScriptResourceMapping 命名的 jquery (區分大小寫)。

解決方式：
在有用 validation 那頁的 Page_Load 加上，就恢復正常了
protected void Page_Load(object sender, EventArgs e)
{
     UnobtrusiveValidationMode = UnobtrusiveValidationMode.None;
}

參考來源：
https://blog.xuite.net/tolarku/blog/63451508-VS+2012+%E5%88%9D%E9%AB%94%E9%A9%97+-+%E9%9C%80%E8%A6%81+%27jquery%27+%E7%9A%84+ScriptResourceMapping+%E9%8C%AF%E8%AA%A4
https://www.c-sharpcorner.com/UploadFile/cd7c2e/enabling-unobtrusive-validation-mode-in-Asp-Net-4-5/

在加入 AD 的主機下, ASP.NET 執行的預設帳號是本機帳號的 IIS_IUSERS 哦.

IIS 7.0 之後 
用 HttpContext.Current.Request.UserHostAddress 抓的IP會是 
類似 fe80::b148:cddc:81cd:fd10%2 
這樣的IPv6 位址
如果要抓 IPv4 要特別改寫

參考
https://dotblogs.com.tw/hunterpo/2011/03/21/21991


HttpContext.Current.Request.UserHostAddress


暫時的替代方法
public static string GetClientIPv4() { string ipv4 = String.Empty; foreach (IPAddress ip in Dns.GetHostAddresses(GetClientIP())) { if (ip.AddressFamily.ToString() == "InterNetwork") { ipv4 = ip.ToString(); break; } } if (ipv4 != String.Empty) { return ipv4; } // 原作使用 Dns.GetHostName 方法取回的是 Server 端資訊，非 Client 端。 // 改寫為利用 Dns.GetHostEntry 方法，由獲取的 IPv6 位址反查 DNS 紀錄， // 再逐一判斷何者屬 IPv4 協定，即可轉為 IPv4 位址。 foreach (IPAddress ip in Dns.GetHostEntry(GetClientIP()).AddressList) //foreach (IPAddress ip in Dns.GetHostAddresses(Dns.GetHostName())) { if (ip.AddressFamily.ToString() == "InterNetwork") { ipv4 = ip.ToString(); break; } } return ipv4; } /// <summary> /// 取得客戶端主機位址 /// </summary> public static string GetClientIP() { if (null == HttpContext.Current.Request.ServerVariables["HTTP_VIA"]) { return HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]; } else { return HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"]; } }

今天發生一個SQL奇怪的現象，記錄一下
就是訂單列表(使用分頁的SQL 找出 top 20)跑很久才出來，大約10多秒 
SQL指令條件僅有訂單日期(預設是1年內訂單，訂單總數有130萬筆)，而訂單日期也有做index
之前都大約1~2秒就出來，這一兩天卻要10秒才跑出來

用執行計畫評估功能查也看不出哪裡有問題，把一些子查詢拿掉也沒有改善
所以就改一下搜尋條件，改搜尋半年內訂單，大約 5秒
改搜尋兩年內訂單，1秒!!! 真是神奇，把條件區間拉大反而很快???????
直覺上覺得索引table是不是太大太亂了，剛好看到CreateDate索引有個重建按鈕
就勇敢把他按下去，想說會不會跑很久，結果重建只要不到1秒就好了
然後神奇的事發生了，訂單列表不須一秒就顯示出來啦!

SQL 指令大概長這樣

Select * from (

Select Top 20 * from (

select Top 20 a.*

--, CompelteOrderId= (select top 1 K.Id from packing_list_main k With(NoLock) join Order_Main p With(NoLock) on k.Order_Id=p.Id where k.En_Packing_List_Status=300 and P.MEmber_Id=a.Member_Id )

--, [MemoCount_前台問題] = (Select COUNT(*) from Order_Memo With(NoLock) where Order_Memo.Order_Id = a.Id and Memo_Type = 1)

--, [MemoCount_業務備註] = (Select COUNT(*) from Order_Memo With(NoLock) where Order_Memo.Order_Id = a.Id and Memo_Type = 3)

--, [MemoCount_系統檢查] = (Select COUNT(*) from Order_Memo With(NoLock) where Order_Memo.Order_Id = a.Id and Memo_Type = 4)

--, QnACount = (select count(*) from Order_QnA With(NoLock) where Order_Id = a.Id)

from V_Order_Main_For_Admin_List a With(NoLock) left join Member b with(NoLock) on a.Member_Id=b.Id where (1=1) and En_Order_Status <> -300 and a.Create_Date >='2018-06-20' order by Id Desc

) AS T1 order by Id

) AS T2 order by Id Desc

參考 will will web 的舊文章，原來定期把索引整理整理，也是要記得做的。
不過週期上我想 1季或半年跑一次應該就可以了
-------------------------------------------------------------------
後記: 2020/6/22 -  一年後又發生一樣的狀況，真是神奇
這次 OrderMain CreateDate 沒有很分散。只有 2.X %
想說其他 index 是不是該重建，但是都沒有效果
最後只好重建 CreateDate --> 結果居然解決了

看 2021年會在發生嗎?

 

先寫幾個, 有空再整理.

1. Upload Folder 的執行權限要關閉
2. 在HTTP Header加入X-Frame-Options: DENY或SAMEORIGIN。
3. web.config 的 connection string 和 app setting 要加密

刪除使用者, 出現 "無法卸除目前使用者已登入的登入" 時, 可以用以下的指令查該 user 的執行緒

sp_who 'sa2'

再用 kill 指令刪除執行緒..