我将下面的代码发布到Sun开发人员论坛，因为我认为这是错误的(真正的错误是在代码被击中之前)。我得到的回应之一说，这是行不通的，请将其丢弃。但这实际上是有效的。它可能不是最好的代码(我是Java的新手)，但是它固有地存在"错误"吗？

=============

我们正在运行的代码实际上是纯粹在Access中的一个JET查询，Java代码除了告诉Access运行查询之外没有执行任何操作。

一方面，如果它没有损坏，请不要修复它。另一方面，它很有可能在不久的将来破裂，因此我们可以尝试提前修复它。

它可能会中断的两个可能原因是：

• SQL注入风险。根据csvDirPath和csvFileName的来源(例如csvFileName可能来自用户上传的文件的名称？)，以及Access JDBC驱动程序的巧妙程度，我们可能会愿意通过插入分号(或者一些用于创建子查询的括号)和一些添加的SQL命令到查询中。
• 我们所依赖的CSV文件列与Access表的列兼容。如果我们未选中要上传的CSV，或者CSV生成器具有处理null的特定方法，或者我们一天有一种不寻常的日期或者数字格式，则在插入Access表时可能会出错。

说了这么多，我们都在这里谈实用主义。如果上面的代码来自一个实用类，我们将每周/每月/每年/曾经几次使用它，那么这实际上不是问题。

如果它是构成Web应用程序一部分的类，则执行此操作的"官方" Java方法是从CSV文件中读取记录(使用CSV解析器或者CSV / text JDBC驱动程序)，记录集之外的列，对其进行一些验证或者健全性检查，然后使用新的PreparedStatement将它们插入Access数据库。麻烦更多，但功能更强大。

我们可能会找到工具的组合(例如，对象关系层或者其他数据访问工具)，这些工具可以为我们完成很多工作，但是设置工具和编写代码一样麻烦。再说一次，我们将从任何一个中学到很多东西。

解决方案

警告一句话jdbc-> Access查询(使用odbc桥接)在64位系统上不起作用，因为不存在64位Access数据库驱动程序(该驱动程序包含在Windows的32位副本中，并且只能由32位用户访问位进程。我们可以运行" odbcad32"或者查看ODBC控制面板以查看驱动程序是否存在)

虽然在代码片段中看不到带有连接字符串的代码，但我不知道任何用于Java的非商业性Access JDBC驱动程序，只有jdbc-> odbc桥接并依靠Windows来具有Access(* .mdb)驱动程序。 Microsoft不再支持此驱动程序，也没有计划将其移植到64位，因此在基础架构方面明智的做法是可以考虑的。

回答

向约书亚·麦金农(Joshua McKinnon)提问：

我们能提供有关MS计划永远不会为Jet引入64位ODBC驱动程序的引用吗？这听起来很合理，所以我一点都不怀疑我们，我只想知道我们是否可以找到它的来源。

当然，MS可以通过OLEDB在64位系统上提供对Jet的访问，对吗？这对JDBC没有帮助，但是肯定提供了一种使用Jet数据的方法(因为Jet 4是OS的一部分，所以它必须提供一些东西，因为Jet 4用作Active Directory的数据存储，因此已经被使用了) (从Windows 2000开始)。

回答

@ david.w.fenton.myopenid.com："我们能提供有关MS永远不会为Jet引入64位ODBC驱动程序的计划的引用吗？"

大卫，我在Microsoft的Connect Feedback中找到了关于此的帖子。

http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125117

"目前，尚无计划由Office团队发布64位版本的JET驱动程序。我们可能会考虑其他选择，并且在有具体计划时会向我们更新。"

谢谢，
SSIS团队。
微软发布于2007年10月3日，晚上9:47

Microsoft在该反馈线程中没有更新。

标题数量不匹配

标题数量不匹配

代码数量不匹配