[英]Inserting NULL in an nvarchar fails in MSAccess

I'm experiencing something a bit strange.


I have a table on SQL Server 2008, say StockEvent that contains a Description field defined as nVarchar(MAX).
The field is set to be Nullable, has no default value and no index on it.

我在SQL Server 2008上有一個表,比如說StockEvent包含一個定義為nVarchar(MAX)的Description字段。該字段設置為Nullable,沒有默認值,也沒有索引。

That table is linked into an Access 2007 application, but if I explicitly insert a NULL into the field, I'm systematically getting:

該表鏈接到Access 2007應用程序,但如果我在字段中顯式插入NULL,我會系統地獲取:

Run-time Error '3155' ODBC--insert on a linked table 'StockEvent' failed.

So the following bits of code in Access both reproduce the error:


Public Sub testinsertDAO()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Set db = CurrentDb
    Set rs = db.OpenRecordset("StockEvent", _
                              dbOpenDynaset, _
                              dbSeeChanges + dbFailOnError)
    rs!Description = Null
    Set rs = Nothing
    Set db = Nothing
End Sub

Public Sub testinsertSQL()
    Dim db As DAO.Database
    Set db = CurrentDb
    db.Execute "INSERT INTO StockEvent (Description) VALUES (NULL);", _
    Set db = Nothing
End Sub

However, if I do the same thing from the SQL Server Management Studio, I get no error and the record is correctly inserted:

但是,如果我從SQL Server Management Studio執行相同的操作,則不會出現錯誤並且正確插入了記錄:

INSERT INTO StockEvent (Description) VALUES (NULL);

It doesn't appear to be machine-specific: I tried on 3 different SQL Server installations and 2 different PCs and the results are consistent.
I initially though that the problem may be in my Access application somewhere, but I isolated the code above into its own Access database, with that unique table linked to it and the results are consistent.

它似乎不是特定於機器的:我嘗試了3種不同的SQL Server安裝和2種不同的PC,結果是一致的。我最初雖然問題可能在我的Access應用程序的某個地方,但我將上面的代碼隔離到它自己的Access數據庫中,並將該唯一表鏈接到它並且結果是一致的。

So, is there some known issue with Access, or ODBC and inserting NULL values to nvarchar fields?


Thanks for the answers so far.
Still no luck understanding why though ;-(


I tried with an even smaller set of assumptions: I created a new database in SQL Server with a single table StockEvent defined as such:

我嘗試了一組更小的假設:我在SQL Server中創建了一個新的數據庫,其中一個表定義為StockEvent:



CREATE TABLE [dbo].[StockEvent](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [Description] [nvarchar](max) NULL


Then linked that table though ODBC into the test Access 2007 application.
That application contains no forms, nothing except the exact 2 subroutines above.

然后通過ODBC將該表鏈接到測試Access 2007應用程序。該應用程序不包含任何形式,除了上面確切的2個子程序。

  • If I click on the linked table, I can edit data and add new records in datasheet mode.
    Works fine.
  • 如果我點擊鏈接表,我可以編輯數據並在數據表模式下添加新記錄。工作良好。

  • If I try any of the 2 subs to insert a record, they fail with the 3155 error message.
    (The table is closed and not referenced anywhere else and the edit datasheet is closed.)
  • 如果我嘗試2個子中的任何一個來插入記錄,它們將失敗並顯示3155錯誤消息。 (該表已關閉,未在其他任何地方引用,編輯數據表已關閉。)

  • If I try the SQL insert query in SQL Server Management Studio, it works fine.
  • 如果我在SQL Server Management Studio中嘗試SQL插入查詢,它可以正常工作。

Now for the interesting bit:


  • It seems that anything as big or bigger than nvarchar(256), including nvarchar(MAX) will fail.
  • 似乎任何大於或大於nvarchar(256)的東西,包括nvarchar(MAX)都會失敗。

  • Anything with on or below nvarchar(255) works.
    It's like Access was considering nvarchar as a simple string and not a memo if its size is larger than 255.
  • 任何在nvarchar(255)之上或之下的東西都可以。這就像Access將nvarchar視為一個簡單的字符串而不是備忘錄,如果它的大小大於255。

  • Even stranger, is that varchar(MAX) (wihout the n) actually works!
  • 更奇怪的是,varchar(MAX)(沒有n)實際上是有效的!

What I find annoying is that Microsoft's own converter from Access to SQL Server 2008 converts Memo fields into nvarchar(MAX), so I would expect this to work.

我覺得煩人的是,微軟自己的轉換器從Access到SQL Server 2008將Memo字段轉換為nvarchar(MAX),所以我希望這可以工作。

The problem now is that I need nvarchar as I'm dealing with Unicode...

現在的問題是我需要nvarchar,因為我正在處理Unicode ...

5 个解决方案


OK, I may have found a related answer: Ms Access linking table with nvarchar(max).


I tried using the standard SQL Server driver instead of the SQL Server Native Client driver and nvarchar(MAX) works as expected with that older driver.

我嘗試使用標准SQL Server驅動程序而不是SQL Server Native Client驅動程序,並且nvarchar(MAX)按預期使用較舊的驅動程序。

It really annoys me that this seems to be a long-standing, unfixed, bug.
There is no valid reason why nvarchar should be erroneously interpreted as a string by one driver and as a memo when using another.
In both cases, they appear as memo when looking a the datatype under the table design view in Access.


If someone has any more information, please leave it on this page. I'm sure others will be glad to find it.



That should be legal syntax. Is it possible that the field you are try to give a null value is linked to other fields that don't allow null values?



Potential concurrency problem... Is the record open by another instance of Access on the same or a different machine, or does a form bound to the table have the record open in the same instance of Access on the same machine?


Renaud, try putting something in one of the other fields when you do the insert.


Also, try inserting an empty string ("") instead of a null.




Did you try running a SQL Profiler trace? If you look at the Errors and Warnings category it should kick out an error if your insert failed as a result of a SQL Server constraint.

您是否嘗試運行SQL事件探查器跟蹤?如果查看“錯誤和警告”類別,如果由於SQL Server約束導致插入失敗,則應該發出錯誤。

If you don't see any errors, you can safely assume that the problem is in your application.


Also, are you sure you're actually connected to SQL Server? Is CurrentDB not the same variable you're using in your Access test loop?

此外,您確定您實際上已連接到SQL Server嗎? CurrentDB與您在Access測試循環中使用的變量不同嗎?


i got annother issue (here my post: link text


In some very rare cases an error arises when saving a row with a changed memo field - same construct explained in my former post but driving sql2000-servers and it's appropriate odbc-driver (SQL SERVER).

在一些非常罕見的情況下,在保存具有更改的備注字段的行時會出現錯誤 - 在我之前的帖子中解釋的相同構造但是驅動sql2000-servers並且它是適當的odbc-driver(SQL SERVER)。

The only weired fix is: to expand the table structure on sql-server with a column of datatype [timestamp] and refresh the odbc-links. That works and releases the show-stopper in this column on this one row ...


Maybe this info can help someone - for me it's history in going further to odbc with sql2008 in changing the datatypes [text] to [varchar(max)].

也許這個信息可以幫助某人 - 對我而言,在將數據類型[text]更改為[varchar(max)]時,使用sql2008進一步使用odbc的歷史。



粤ICP备14056181号  © 2014-2020 ITdaan.com