请原谅我的愚蠢，我不知道这是否可能。
情况是这样的。
有一个 MS Access“数据库”（是的，我知道，相信我，我知道），我需要从远程位置对其进行选择、更新和插入。问题是这需要安全地进行。
我可以完全控制托管 MS Access 文件的远程计算机，因此我可以根据需要安装驱动程序和软件。服务器是 Microsoft Windows Server 2003。
我打算采用的方法是在 HTTPS 服务器上托管 PHP 脚本（使用 Apache 或 IIS，并不重要），将 XML 发送到 PHP 脚本，然后 PHP 脚本将执行其操作MS Access 数据库上的东西并将 XML 结果发回。然而，由于时间限制，我试图弄清楚是否可以以安全的方式直接通过 ODBC 连接，并让它与 MS Access 数据库通信。
据我了解，ODBC 并不以安全着称，但有支持加密连接的 ODBC 驱动程序，或者我可以以某种方式通过 SSL 建立 ODBC 连接隧道。然而，到目前为止我发现的所有信息都依赖于 Microsoft SQL 数据库。
我特别感兴趣是否有方法可以在不考虑底层数据库的情况下对 ODBC 连接进行 SSL 化。我可能可以自己在 Unix 克隆上解决这个问题，但主机是 Windows Server 2003，在这种情况下，我不知道如何继续。
这有可能吗？任何信息都高度赞赏！
Pardon my outrageous silliness, I don't know if this is even possible.
Here's the situation.
There is an MS Access "database" (yes, I know, believe me, I know) which I'll need to SELECT, UPDATE and INSERT to from a remote location. The catch is that this needs to happen securely.
I have complete control over the remote machine which hosts the MS Access file, so I can put in drivers and software as I please. The server is Microsoft Windows Server 2003.
The approach that I had intended to take was to host a PHP script on an HTTPS server (using either Apache or IIS, doesn't matter), send XML to the PHP script which would then do its thing on the MS Access database and send XML results back. However, due to time restraints, I'm trying to figure out if I can connect directly through ODBC in a secure manner, and have it speak to an MS Access database.
It's my understanding that ODBC is not exactly famous for being secure, but that there are ODBC drivers that support encrypted connections, or that I can somehow tunnel the ODBC connection through SSL. However, all the information I have found so far relies on the database being Microsoft SQL.
In particular I'm interested if there are ways to SSL-ify ODBC connections without regard to the underlying database. I could probably figure that out on a Unix-clone by myself, but the host is a Windows Server 2003 in which case, I don't know how to proceed.
Is this possible at all? Any information highly appreciated!
发布评论
评论（3）
这里的问题是您不太了解 ODBC 连接如何与访问一起工作。我们这里讨论的不是 TC/IP 或基于 socked 的连接。
如果您查看 JET 访问文件的任何连接字符串，您会发现 ODBC 连接中将始终包含完全限定的 Windows 路径名，我重复一遍。当我说完全限定的 Windows 路径名时，我指的是位于硬盘上的文件。
归根结底，我们讨论的是打开一个普通的 Jane Windows 文件。马是马是马，windows文件是windows文件，是windows文件。
换句话说，我们正在谈论打开硬盘上的文件。因此，整个过程与打开 Excel 文件、文本文件、PowerPoint 文件或在本例中恰好位于硬盘上的访问文件没有任何不同。
此文件所在的计算机上无需安装任何服务器或特定数据库软件。客户端必须拥有该软件并执行标准的 Windows 文件打开命令以从磁盘驱动器中提取数据。请记住，当您将 Word 文件放在服务器上并打开它时，您不必在服务器上安装 Word，这是执行 Windows 标准文件打开的客户端，并且在打开访问文件时，完全相同的情况适用于 JET 。
这意味着如果您要通过 Internet 连接打开此文件，则必须通过 Internet 扩展 Windows 网络。 HTTP 甚至 FTP 与 Windows 文件网络协议相差甚远。
但是，您可以通过 Internet 扩展 Windows 网络系统，这通常是通过称为 VPN（虚拟专用网络）来完成的。这意味着您必须设置 VPN。因此，这将允许您通过网上邻居查看另一台计算机，并浏览到服务器上该文件夹中的文件，然后将其打开。再次打开标准 Windows 文件时，服务器上没有运行某种类型的服务，您可以像 SQL Server 那样连接到该服务。
您可以阅读我的以下文章，我解释了为什么使用 Windows 网络和 JET（访问）文件在 Internet 上运行 VPN 根本无法以可靠的方式工作：
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
所以，请记住如果您查看任何 JET ODBC 连接字符串，您会发现它绝不是基于 IP 的，而必须是完全限定的标准 Windows 文件名。我不能再次强调并重复，我们正在谈论我们要打开的标准 Windows 文件名和位置。
请记住，这与打开 Word、Excel 或 PowerPoint 没有什么不同。 ODBC 驱动程序混淆了这个问题，因为该驱动程序只需要在客户端安装和设置，除了需要打开标准纯简 Windows 文件的能力之外，不需要在服务器端连接两个驱动程序。
因此你要求用VPN尽可能，但不实用。您可以阅读上面的文章，它详细解释了为什么它不能可靠地工作和运行。
随着 SQL Server 的多个免费版本以及许多其他选择的出现，上述限制可能不会成为您的问题。这些其他服务器数据库系统不是基于文件的，并且您的连接字符串永远不会解析为某些文件名。并且，因此这些数据库服务器也不需要 Windows 网络原型调用来打开该文件，因此您甚至可以连接到甚至没有安装 Windows 网络的服务器，例如运行 Linux 等。对于jet 连接，您必须使用Windows 网络直接打开文件。
The problem here is you are not quite understanding how an ODBC connection works with access. We are not talking about a TC/IP or socked based connection here.
If you look at ANY connection string for an JET to access file, you see in the ODBC connection will always, I REPEAT ALWAYS include a fully qualified windows path name. When I say a fully qualified windows path name, I am talking to about a file that sitting on the hard disk.
At the end of the day we are thus talking about opening a plain Jane windows file. A horse is a horse is a horse and a windows file is a windows file, is a windows file.
In other words we are talking about opening a file sitting on the hard disk. So, this whole process is not any different than opening excel file, a text file, a PowerPoint file, or in this case an access file that just also happens to be sitting on the hard disk.
There's no server or particular database software that EVER has to be installed on the computer where this file sets. It is the CLIENT SIDE that must have the software and execute a standard windows file open command to pull the data off the disk drive. Remember when you place a word file on a server and open it, you never had to install word on the server, is the client side that's doing a windows standard file open, and the exact same scenario applies to JET when it opens a access file.
What this means then if you're going to open this file up over an Internet connection, you therefore must extend windows networking over the Internet. HTTP, or even FTP is nothing remotely close to the windows file networking protocol.
However, you can extend windows networking system over the Internet, and this is typically done by which called a VPN (virtual private network). That means you'll have to set up a VPN. This will thus allow you to see this other computer via network neighborhood and browse to the files on that folder on the server, and simply open it. Again your opening a standard windows file, there's not some type of service running on the server that you can connect to like with SQL server.
You can read the following article of mine and I explain why running a VPN over the Internet with windows networking and a JET (access) file simply will not work in an reliable fashion:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
So, just keep in mind that if you look at any JET ODBC connection string, you'll notice it's never a IP based, but must be a FULLY QUALIFIED STANDARD windows file name. I cannot stress and repeat again that we talking about a standard windows file name and location that we going to open.
Remember this is no different than opening word or excel or PowerPoint. The ODBC driver confuses this issue, since the driver is ONLY required to be installed and setup on the client side, there's nothing to connect two on the server side, except the required ability to open a standard plain Jane windows file.
What you thus ask as possible with a VPN, but not practical. You can read the above article and it explains in detail why this cannot reliably work and function.
With the advent of several free editions of SQL server, and so many other choices, the above limitation is likely not going to be an issue for you. These other server database systems are not file based, and your connection strings will NEVER resolve to some file name. And, thus these database servers also do not require the windows networking proto call to open that file, and therefore you can even connect to servers such as running linux etc. that don't even have windows networking installed. For a jet connection, you have to use windows networking to directly open the file .
通常在客户端和数据库之间放置一个中介。中介处理身份验证、授权、安全数据传输等。您假设数据库位于防火墙内的安全区域中。您想要添加的所有内容，以确保防火墙之外的客户端的安全，都由中介处理。
作为一名 Java 人员，我会自然而然地认为 Web 客户端与一个或多个 servlet 进行通信。让 servlet 处理身份验证和授权。 HTTP 意味着无需担心防火墙。您也可以使用 HTTPS。
我认为这会更容易实施。此外，即使是 SSL 化的 ODBC 连接仍然会将您的数据库暴露给更广泛的 Internet。我不希望我的数据存放在这样的存储库中。你愿意吗？
Usually one puts an intermediary between clients and the database. The intermediary handles authentication, authorization, secure data transmission, etc. You assume that the database is inside your firewall, in a secure area. All the things you want to add to make things secure for clients that are outside your firewall are handled by the intermediary.
Being a Java person, I would automatically think web client talking to one or more servlets. Let the servlet handle authentication and authorization. HTTP means no firewall worries. You can use HTTPS, too.
I think that'd be easier to put in place. Besides, even an SSL-ified ODBC connection still exposes your database to the wider Internet. I wouldn't want my data in such a repository. Would you?
为什么您的 MS-Access（真正的 MS-Jet）数据库只有 1 个文件？
我无法想象。如果它不是 ODBC 数据库，那么我可以想象它。
大多数 MS-Jet ODBC 数据库中都有 100 个 *.MDB 文件，
其中每个 MDB 文件充当：单个表、表组或部分表，在逻辑上和物理上分布（未拆分，且无链接）跨数十个或数百个 MDB 文件。没有 MDB 文件本身被视为数据库。
这就是我所看到的使用 MS-Access 驱动程序构建的 ODBC 数据库的方式
MS-喷气发动机。
大多数 ODBC MS-Jet/MS-Access 驱动程序数据库大约有 50 亿行，大小为 1 TB。
Why does your MS-Access (really MS-Jet) database have only 1 file?
I can't picture that. If it were not an ODBC database, then I can picture it.
Most MS-Jet ODBC databases have 100's of *.MDB files in them,
where each MDB file is acting as either a: single table, group of tables, or partial table that is logically and physically spread (not split, and with no linking) across dozens or 100's of MDB files. No MDB file is considered a database in and of itself.
This is how I have seen ODBC databases built using the MS-Access Driver and
MS-Jet Engine.
Most ODBC MS-Jet/MS-Access Driver databases are around 5 billion rows and 1 Terabyte in size.