或者,您可以通过使用视图将服务器端布尔值 CAST() 转换为 INT,以处理 BIGINT 问题的方式来处理它.这使其不可编辑,但(与 BIGINT 一样),您可以将原始字段保留在 VIEW 中并使用适当的值写入该字段,而 CAST() 版本仅用于显示.就其价值而言,SSMA for Access 将 Jet/ACE 布尔值提升为可空位字段(但不确定为什么它们可以为空——我可能需要检查我的一些应用程序以确保它们正常工作!).Looks like I'm not the only one out there with this issue, but there doesn't seem to be an anwwer to this problem.I'm working in Access 2010, using a linked table to an SQL Server 2005 database (through an SQL Server ODBC pipe). In that table, one of the boolean fields is marked as nullable, and several records in this table do in fact have a null in the field. So far so good.In comes Access, and as soon as you open the linked table, Access shows a 0 (false) instead of a blank cell (problem #1). And if you try to modify anything in the record, you get an error message saying the record was modified by someone else and your changes cannot be saved. This last problem is due to the fact that Access doesn't tolerate nullable bool fields, and goes a bit nuts when trying to save the value.My research shows that this could have something to do with Access using Jet in the background to connect to the SQL Server database, and Jet apparently does not support nullable bools. There doesn't seem to be a way to configure Jet to support this (although perhaps there is, if you're connecting in code). I also thought MS was replacing Jet with another technology used in Office 2010 (ACE, I think), but cannot tell if this is what's actually being used by Access. In either case, I can find no configurable options regarding nullable bools.Finally, this issue seems to have been brought up to MS a short while ago, but there's no answer on their end: https://connect.microsoft.com/SQLServer/feedback/details/617339/null-bit-fields-produce-spurious-ms-access-errors-when-using-the-native-odbc-driver?wa=wsignin1.0#tabsI'm wondering if anyone else out there has run into this and found a solution. And before you suggest it, taking the nullable option off and setting all nulls to 'false' is not really an option in our case. For us, null is actually a valid state and very different from 'false.Thx! 解决方案 ACE is an upgrade of Jet (forked from the Jet 4.0 codebase, which is maintained by the Windows team and not seeing any further development, while ACE is under full development by the Access team). It's not significantly different from Jet, except in that it's a new version of the database engine and has features that Jet lacked.Nullable Booleans are not one of the added features. In any case, if I'm not mistaken there are big theoretical arguments about whether Booleans should be Nullable and Jet/ACE comes down on the side that says they shouldn't be.Non-nullable Booleans cause problems even within Access/Jet/ACE (Allen Browne has discussed one such, with LEFT JOINs). My suggestion is that you change the field to a Nullable Bit, Byte or Integer field (I'm not sure what exact data types are in SQL Server, nor what is going to be most compatible with Access/Jet/ACE).Alternatively, you can approach it the way the BIGINT problem is dealt with by using a view to CAST() the server-side Boolean to an INT. That makes it non-editable but (as with BIGINT), you can keep the original field in the VIEW and write to that with appropriate values, while the CAST() version is for display only.For what it's worth, the SSMA for Access upsizes Jet/ACE Booleans to nullable bit fields (not sure why they are Nullable, though -- I may need to check some of my apps to make sure they are working correctly!). 这篇关于MS Access 链接表中的可空布尔字段的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持! 上岸,阿里云!
08-02 01:00