程式實驗室--ProgLab

在開始使用Entity Framework後，一切的ORM都是用.NET Entity Framework來自動產生的。 查詢資料庫的方式也改用了LINQ的語法。例如要查詢某資料表某欄位是否為某等定字串時，可以用如下的語法： var result = from myRow in myTable where myRow.Name == "MyFirstName" select myRow; 但神奇的是，某一天這段語法失靈了。就算資料庫中有符合條件的資料也無法被篩選出來。 如果將語法改為使用StartWith()的方式，則可以正常地找出所要的資料。 var result = from myRow in myTable where myRow.Name.StartWith("MyFirstName") select myRow; 此時開始懷疑是不是資料庫裏那個欄位的資料後面是有空白字元的。這個資料欄位一開始時是以ncahr()的方式開立的，在輸入一些資料後，因為設計上的調整，所以改為使用nvarchar()的型別。 於是就用SQL指令去查了一下資料欄位的字串長度是不是含有空白字元，使用的SQL語法如下： select Name, LEN(Name) as NameLength from myTable 由顯示的結果來看，資料欄裏字串的長度也沒錯啊，看來是沒有包含空白字元。但使用LINQ的語法就是無法用==的方式來查詢所要的資料。 後來想說去查一下SQL的 LEN() 函式的定義，看看是否有特別的部份。哇，原來函式的定義如下，是不包含尾部的空白字元的耶。那如果要查看原始字串長度要用哪個函式呢? Returns the number of characters of the specified string expression, excluding trailing blanks. 原來要查到真正的原始字串長度的話，要用 DATALENGTH() 才行。 一查之下才知道，原來原本用ncahr()改為nvarchar()後，原先輸入的字串資料還是保留了原本後面的空白字元。 如果要修改資料的話，可以用以下的SQL指令： update myName = RTRIM(my...

最近突然想到快兩年前試寫過的WCF程式好久沒拿出來玩玩了。沒想到今天一拿出來，剛執行後就給我來個錯誤訊息。 忘了之前是不是也有發生過這樣的問題了，真覺地想說應該是安全性設定的問題(其實它上面就有提到了)。於是就去看了一下WCF Client端的安全性設定。 在app.config中有一段是有關安全性設定的：security。 看了一下目前的設定，發現它所使用的安全性認証模式是Transport。接著又去看了一下WCF Host端的app.config中的安全性設定，發現它設定的是None。兩邊所使用的方式不同，應該就是問題的所在了。於是就將WCF Client端的安全性設定改得跟WCF Host端一樣。這樣一來兩邊的資訊就能互通了。