在MSAccess中,在nvarchar中插入NULL失敗

[英]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:

因此Access中的以下代碼位都會重現錯誤:

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.AddNew
    rs!Description = Null
    rs.Update
    rs.Close
    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);", _
               dbSeeChanges
    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?

那么,是否存在Access或ODBC的一些已知問題並將NULL值插入nvarchar字段?

Update.
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:

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

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

GO

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 个解决方案

#1


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

好的,我可能找到了一個相關的答案:Ms鏈接表與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.

我真的很惱火,這似乎是一個長期存在的,未經修復的錯誤。沒有正當理由說明為什么nvarchar應該被一個驅動程序錯誤地解釋為字符串,並且在使用另一個驅動程序時作為備忘錄。在這兩種情況下,當在Access中的表設計視圖下查看數據類型時,它們顯示為備忘錄。

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

如果有人有任何更多信息,請將其保留在此頁面上。我相信別人會很高興找到它。

#2


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?

這應該是合法的語法。您嘗試提供空值的字段是否可能鏈接到不允許空值的其他字段?

#3


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?

潛在的並發問題...是否在同一台或另一台機器上由另一個Access實例打開記錄,或者綁定到該表的表單是否在同一台機器上的同一Access實例中打開了記錄?

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

Renaud,在插入時嘗試將其他字段放在其中一個字段中。

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

另外,嘗試插入空字符串(“”)而不是null。

#4


Renaud,

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測試循環中使用的變量不同嗎?

#5


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 ...

唯一可靠的修復方法是:使用數據類型[timestamp]列擴展sql-server上的表結構並刷新odbc-links。在這一行中,這一點有效,並且在這一欄中發布了...

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的歷史。


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2009/06/11/729e4856bb1a9cedbbe29b16323eb537.html



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