衆所周知，使用SQL Server後端的MS Access應用程序（MDB）在某些數據類型中遇到問題。例如，從文本移動到varchar（MAX）：MS Access有什麼麻煩嗎？
現在我們正在考慮從移動文本/ NTEXT字段VARCHAR（MAX）/爲nvarchar（MAX）領域，as recommended by Microsoft：
的ntext，文本和圖像數據類型將在Microsoft SQL Server的未來版本中刪除。避免在新的開發工作中使用這些數據類型，並計劃修改當前正在使用它們的應用程序。改爲使用nvarchar（max），varchar（max）和varbinary（max）。
難道我們要碰上這樣做麻煩嗎？
我們是在同樣的情況：MS-接入前端，SQL Server的後端。我們已經將所有新字段創建爲nvarchar（max）而不是ntext，在用戶端沒有任何問題。因爲我們不使用文本或圖像字段類型，所以我不能對它們說什麼。
在工作中，我們有相同的設置，以及（Access 2003中前端，SQL Server 2005的後端），我們則是問有關做了什麼：
我們有SQL Server表與text/ntext列，我們將它們更改爲varchar(max)/nvarchar(max)。
我們根本沒有遇到任何問題，如果我正確記得它，我們甚至不需要重新鏈接Access中的表格......它只是工作。
好了，我們肯定了最近一個陷阱。問題在於，即使字段被定義爲varbinary（max），也無法將超過8000個字節寫入鏈接表的varbinary字段。
我知道這是一個老帖子，但我認爲它仍然是相關的一些人。我使用從Access Memo字段擴展到SQL的舊數據處理很多事務，然後在Access中轉換爲鏈接表。
我發現擴展到NVARCHAR（最大值）並鏈接表內造成的問題。根據您建立Access Link表的驅動程序，問題會有所不同。
使用SQL Native Client的10我的第一個發現是，Access將字段作爲NVARCHAR（4000）。雖然使用SQL Server作爲驅動程序確實會改變這些問題，但仍然存在問題。對於這個較老的驅動程序來說，這些問題似乎很難追查，但顯示出來。通常具有類似的尺寸問題。
請注意，什麼似乎運行良好，可能實際上只是正確運行，因爲正確的情況下還沒有被擊中。
如果您發現您的字段數據永遠不需要超過4000個字符，則將其設置爲NVARCHAR（4000）。無論如何，如果你只需要4000就可以設置MAX。