ms-access 本地化和默认布尔值
我们的访问客户端即时生成 SQL 插入、更新和删除指令,并在 MS-SQL Server 上发送。大多数用户拥有 Access 2007 的运行时版本,少数用户使用完整的 MS-Access 版本(2003 或 2007)。今天早上,我们国外的一位新用户使用 Access 2003 的法语/完整版本,无法更新包含以下内容的数据:布尔字段。
在法语版 Access 中,这些字段似乎填充了“Vrai/Faux”而不是“True/False”值。通过安装2007 access运行时解决了该问题。
但我想找到一个永久的解决方案,我可以从某个地方读取正在使用的 Access 的本地化版本,并将本地化的 True/False 值“翻译”为标准 True/False。我已经检查了计算机的区域设置但没有成功,所以它在其他地方。有什么想法吗?
编辑:按照 JohnFX 的提议,可以使用这个简单的函数有效地将本地 True/False 转换为通用 True/False:
Function xBoolean(xLocalBooleanValue) as Boolean
if cint(xLocalBooleanValue) = -1 Then
xBoolean = True
endif
if cint(xLocalBooleanValue) = 0 Then
xBoolean = False
endif
end function
编辑:按照 @David 的评论,我更改了最喜欢的解决方案。他的提议比我的聪明。
编辑:我通过读取记录集中字段的值来获取 Vrai/Faux 值:
? debug.print screen.activeForm.recordset.fields(myBooleanField).value
Vrai
Our access client generates on the fly SQL inserts, update and delete instructions to be sent on a MS-SQL Server. Most users have the runtime version of Access 2007, and a few use the complete MS-Access version, 2003 or 2007. This morning one of our new users abroad, using a french/complete version of Access 2003, was unable to update data containing boolean fields.
It appeared that these fields are, in the french version of Access, populated with "Vrai/Faux" instead of "True/False" values. The problem was solved by installing the 2007 access runtime.
But I'd like to find a permanent solution, where I'd be able to read from somewhere which localized version of Access is in use and 'translate' the localized True/False values to standard True/False. I already checked the regional settings of the computer without success, so it is somewhere else. Any idea?
EDIT: Following JohnFX proposal, it is effectively possible to convert from local True/False to universal True/False with this simple function:
Function xBoolean(xLocalBooleanValue) as Boolean
if cint(xLocalBooleanValue) = -1 Then
xBoolean = True
endif
if cint(xLocalBooleanValue) = 0 Then
xBoolean = False
endif
end function
EDIT: following @David's comments, I changed the favorite solution. His proposal is smarter than mine.
EDIT: I am getting the Vrai/Faux values by reading the value of a field in a recordset:
? debug.print screen.activeForm.recordset.fields(myBooleanField).value
Vrai
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
在所有情况下,无论本地化或数据库格式如何,True 都不是 FALSE 或 NOT 0。
因此,如果您将 True 的所有测试替换为 NOT 0,将 False 的所有测试替换为 =0,那么您就避免了 Access 关键字的本地化问题(令我惊讶的是,VBA 以及 Jet 和 Access 表达式服务不会但仍然理解 True/False),以及数据库引擎用于存储布尔值的任何约定。
一般来说,您的数据访问层应该为您抽象出来。根据我的经验,ODBC 和 ADO 都会自动执行此操作,因此您可以使用您知道的布尔值,并且它会以透明的方式为您处理。
我仍然对这个问题感到困惑,因为它听起来像是显示/格式问题,但对 True 和 False 使用 NOT 0 和 =0 可以在所有情况下完全避免该问题。
编辑:关于编辑为菲利普问题的函数:
是否有理由将函数的参数隐式定义为变体?你是这个意思吗?如果传递的是 Null,则第一个 CInt() 会出错,因为 CInt() 不能接受 Null。
另外,还有一个逻辑问题,在 VBA 中,除 0 之外的任何数字都应该返回 True。这也是完全冗余的代码。这更简单,并且在所有情况下都返回正确的结果:
或者,更简洁:
处理参数中传递的空值:
我不确定这在您当前使用它的上下文中是否必要,但我总是讨厌在其中编写代码我可以想象一种情况,它会出错——即使我知道它在当前上下文中无法中断,你永远不知道它最终会在哪里被使用,所以如果你预期可以处理的情况,你应该处理它。
过早优化?
不——它是在武器上加一个安全锁,以防止其被滥用。
(另一方面,如果处理预期错误需要比函数开始时更多的代码行,我会三思而后行)
True is NOT FALSE, or NOT 0, in all cases, no matter the localization or the database format.
So, if you replace all tests for True with NOT 0 and all tests for False with =0, then you've avoided the issue of localization of the Access keywords (I'm surprised that VBA and the Jet and Access expression services would not still understand True/False, though), as well as whichever convention your database engine uses for storing Boolean values.
In general, your data access layer ought to be abstracting that away for you. Both ODBC and ADO do it automatically, so you work with the Boolean values you know and it's taken care of for you transparently, in my experience.
I'm also still puzzled about the question, as it sounds like a display/formatting issue, but use NOT 0 and =0 for True and False avoids the problem entirely in all cases.
EDIT: In regard to the function edited into Philippe's question:
Is there a reason you've implicitly defined your function's parameter as a variant? Is that what you mean? If it's passed a Null, it's going error out on the first CInt(), as CInt() can't accept a Null.
Also, there's a logic problem in that in VBA any number but 0 is supposed to return True. It's also completely redundant code. This is simpler and returns the correct result in all cases:
Or, pithier still:
And to handle Nulls passed in the parameter:
I'm not sure that's necessary in the context you're currently using it, but I always hate writing code where I can imagine a case where it will error out -- even if I know it can't break in its present context, you never know where it might end up getting used, so should you anticipate a condition that can be handled, you should handle it.
Premature optimization?
No -- it's putting a safety lock on a weapon that keeps it from being misused.
(on the other hand, if it took more lines of code to handle the antipated error than the function started out with, I'd think twice about it)
您是否考虑过在更新和删除查询中使用 -1/0(Access 对于布尔值很奇怪)而不是 true/false?
你知道,数学是通用语言。
另外,为了避免对 UI 进行过多本地化,为什么不在 UI 上使用复选框而不是布尔值文本字段呢?
Have you considered using -1/0 (Access is weird about booleans) instead of true/false in your update and delete queries?
Math is the universal language, yaknow.
Also, to avoid having to localize the UI so much, why not use check-boxes instead of a text field for booleans on your UI?
简单的:
Simple: