访问数据库共享策略
您采用什么策略让多人在 Access 数据库上工作？
是否可以在线托管它并使其功能仍然有效，而无需开发自定义前端？
MS Access 作为一款软件，有一些不错的功能，无需任何编程即可配置：
- 下拉列表 - 选择一个
- 多复选框列表 - 选择多个
即使在线托管，是否也可以使用所有这些功能？我基本上正在考虑另一种方法来快速让人们使用上述 GUI 功能来处理数据，而无需采用 webapp<>MySQL 方式。
What are the strategies you employ to let multiple people work on an access database?
Is it possible to host it online and have its features still functional without having to develop a custom frontend?
MS Access as a software has a few nice features that don't require any programming to configure:
- Drop down lists - choose one
- Multi Checkbox lists - choose multiple
Is it possible to get all of these features available even when hosted online? I'm basically thinking of an alternate way to quickly get people to work with data using GUI features like the above without going the webapp<>MySQL way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你在这里有一些很好的评论。请记住，Access 2010 的情况发生了很大变化。Access
2010 允许您构建 Web 应用程序。开发过程与多年来非常相似，但您不能在这些 Web 应用程序的表单中使用 VBA（您使用新的宏语言）。这个新功能集允许您将构建的应用程序发布到网站。这是我在 Access 2010 中运行的应用程序的视频，在视频的中间点，我切换到在 Web 浏览器中 100% 运行 access 应用程序：
http://www.youtube.com/watch?v=AU4mH0jPntI
以上内容适用于 2010 年访问…将于今年发布。上述要求您运行 SharePoint 服务，或使用支持“访问 Web”服务的托管服务。
对于以前版本的访问，无论出于何种意图和目的，它根本不是基于网络的系统。现在，当您说多个用户时，您必须澄清用户类型以及他们计划成为何处。如果您的用户位于本地办公网络上，那么 MS Access 可以立即用作多用户系统，无需额外的编码和编程。但是，建议您将应用程序拆分为部署在每个用户计算机上的前端部分。我的以下文章概述了这个概念。
http://www.members.shaw.ca/AlbertKallal/Articles/split /index.htm
现在，也许用户将使用笔记本电脑并且分布在全国各地？在这种情况下，您尝试通过广域网进行连接，或者让用户通过 Internet 连接到应用程序。这是一个不同的问题。在这种类型的场景中，一个好的解决方案是使用 SQL Server 之类的东西作为后端，然后继续将 Access 前端部署到每个用户的计算机上。该应用程序往往也是最便宜的。使用 sql server + ms-access 意味着您可以像往常一样继续在 Access 中进行开发。另一种无需求助于 SQL Server 即可实现广域使用的方法是使用称为终端服务的东西。我在下面的文章中概述了这些可能性：
http://www.members.shaw .ca/AlbertKallal//Wan/Wans.html
如前所述，这里的其他一些人发布了一些您可以考虑使用的 SharePoint 新功能的链接，但它们要到今年晚些时候才会发布。
You have some good comments here. Keep in mind that things have changed quite a bit for access 2010.
Access 2010 allows you to build web applications. The development process is very much the same as it’s been for years, but you can’t use VBA in forms for these web applications (you use a new macro language). This new feature set allows you to publish applications you build to a website. Here is an video of an application of mine running in access 2010, and at the halfway point in the video I switch to running the access application 100% in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
The above is for access 2010…due out this year. The above will require you to be running SharePoint services, or use an hosting service that supports "access web" services.
For previous versions of access, for all intents and purposes, it’s not a web based system at all. Now when you say multiple users, you have to clarify what kind of users and where they plan to be. If your users are on a local office network, then MS access can be used as a multi user system right out of a box with no additional coding and programming required. It is recommended however that you split your application into a front end part that’s deployed on each user’s computer. This Concept as outlined in the following article of mine.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Now, perhaps the users are going to be on notebooks and in different locations all over the country? In this type of case you are attempting to connect over a wide area network, or have users connect to the application over the Internet. This is a different problem. In this type of scenario, a good solution is to use something like SQL server for the backend, and you continue to deploy the Access front ends to each user’s computer. This application tends to be about the most cost affordable also. And using sql server + ms-access means you get to continue developing in Access for the most part like you always done. Another way to accomplish wide area use without resorting to sql server is to use something called terminal services. I outline these possibilities in the following article:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
As mentioned, a few others here posted links to some of the new SharePoint features that you can consider using, but they not out untill later this year.
对于 15-25 名护林员或更小的小型工作组用户群体来说，多用户访问应用程序非常容易实现。除此之外，开发人员应考虑升级到服务器后端，其代价是服务器的管理开销更大，而如果保留 Jet/ACE 后端则必须更仔细地对应用程序进行编程。
至于在线访问，这不可能通过 HTTP 实现，但如果您有可用的 Windows 终端服务器，您可以在那里托管您的应用程序并授予用户访问权限。这实际上是支持应用程序远程用户的一种极其简单、高效且廉价的方式，尽管用户群体越大，问题就越大。但是，当 Access 应用程序的用户数量对 Windows 终端服务器设置造成压力时，您将不再使用 Jet/ACE 后端。
借助服务器后端，您可以通过 Internet 访问 VPN 上的 SQL Server，如果您非常高效地编写 Access 应用程序，即使通过标准宽带连接，您的用户仍然可以高效工作。
然后是 Access 的未来：在 Access 2010 中，已经做了大量工作来与 Sharepoint 2010 中的许多新功能集成。如果您使用新型 Access Web 表单和报表创建 A2010 应用程序，您的应用程序可以上传到运行新 Access Services 的 Sharepoint 服务器，然后可以在 Web 浏览器（不限于 IE）中运行，并且不依赖于任何插件或 Web 控件，就像过去完全毫无价值的情况一样访问数据访问页）。数据存储可以是 SQL Server，也可以将其保留为 Jet/ACE（供不通过 Web 浏览器访问的用户使用），并将数据存储在 Sharepoint 中供在线用户使用。此外，您还可以在 Access 中本地运行一个与 Sharepoint 集成的应用程序，该应用程序在连接到 Internet 时使用 Sharepoint，并且在断开连接时仍然能够脱机工作。再次连接时，您可以将本地更改与 Sharepoint 服务器同步，解决任何差异并继续工作。
这些功能确实非常出色，根据我所听到和看到的，如果 Access 应用程序完全由 Web 表单和报告构建，那么在 Access 中运行时以及通过 Sharepoint 在 Web 浏览器中运行时，它的外观和功能将相同。如果您需要拥有不向在浏览器中运行应用程序的用户公开的客户端功能，您仍然可以使用传统的 Access 对象！
Access 开发团队的博客 有许多关于 A2010 即将推出的内容的帖子，其中有那里发布了一段精彩的视频，演示了 A2010 如何与 Sharepoint 2010 的新访问服务集成。
这构成了 Access 网络功能的巨大飞跃，而这在以前几乎是不存在的，我对此感到非常兴奋。我以前对 Access 所做的更改非常谨慎，这些更改似乎完全是为了使其成为 Sharepoint 的仆人，但现在我可以看到，Access 用户和 Access 开发人员的好处将是巨大的。
Multi-user Access apps are pretty easy to do for small workgroup user populations in the 15-25 ranger or smaller. Above that, a developer should consider upsizing to a server back end, with the trade-off being greater administrative overhead for the server vs. having to program the app more carefully if you retain the Jet/ACE back end.
As to online access, you this isn't possible over HTTP, but if you have a Windows Terminal Server available, you can host your app there and give users access to that. This is actually an extremely easy and efficient and inexpensive way to support remote users of an app, though the larger the user population, the more problematic it becomes. But by the time an Access app has a user population that would strain a Windows Terminal Server setup, you're no longer going to be using a Jet/ACE back end.
And with a server back end, you could give access to a SQL Server on a VPN over the Internet, and if you write your Access app really efficiently, even over a standard broadband connection, your users could still work productively.
Then there's the future of Access: in Access 2010, a great deal of work has been done to integrate with a host of new features in Sharepoint 2010. If you create your A2010 app using the new type of Access web forms and reports, your app can be uploaded to a Sharepoint server running the new Access Services, and it can then be used running in a web browser (not limited to IE and not dependent on any plugins or web controls, as was the case in the past with the completely worthless Access Data Access Pages). The data store can either be a SQL Server, or you could keep it Jet/ACE for users not accessing it via the web browser, and have the data stored in Sharepoint for the online users. Also, you can have an app integrated with Sharepoint running locally in Access that uses Sharepoint when connected to the Internet, and still be able to work offline when disconnected. When connected again, you synch your local changes with the Sharepoint server, resolve any differences and continue working.
The features are really quite remarkable, and according to what I've heard and seen, if the Access app is built entirely of web forms and reports, it will look and function identically when run in Access and when run in the web browser via Sharepoint. And if you need to have client-side features that you don't expose to the users running the app in the browser, you can still use traditional Access objects!
The Access development team's blog has a number of posts on what's coming in A2010, and there's a good video posted there demonstrating how A2010 integrates with Sharepoint 2010's new Access Services.
This constitutes a quantum leap in Access's web capabilities, which were previously almost non-existent, and I'm quite excited about this. I was formerly quite wary of the changes being made to Access that seemed entirely to make it a servant of Sharepoint, but now I can see that the benefit to Access users and Access developers will be huge.
我听说过的一种方法是将 Access 数据库导入到 SQL Server 数据库中。
（几乎任何版本都可以。）。
然后用Access链接到SQL Server数据库，让用户像以前一样使用它。
查看此链接： http://office.microsoft.com/en-us /access/HA010345991033.aspx
如果您想要一个在线解决方案，我建议您使用普通的 Web 应用程序架构。 （与适当的数据库交谈。）。
One way i've heard of, is to import the access database into a SQL Server database.
(Almost any version will do.).
Then link to the SQL Server database with Access and let users use it as they did before.
Look at this link: http://office.microsoft.com/en-us/access/HA010345991033.aspx
If you want an online solution i'd recommend going with a normal web application architecture. (Talking to a proper database.).
我自己从来不需要支持它，但从目前为止我所听到的情况来看，一旦需要支持多个用户同时写入，性能就会急剧下降。我认为这是因为 Access 使用简单的文件锁定来实现隔离，而这对于并发数据库系统来说不是正确的技术。
I have never needed to support it myself, but from what I heard so far, performance dramatically breaks down as soon as you need to support multiple users writing simultaneously. I think this is because Access uses simple file locking to implement isolation, and this just is not the right technique for a concurrent database system.
在线托管？你是说在网络上吗？从技术上讲，它可以在网络上运行，但 MS-Access 不在 Visual Studio 中是有原因的 - 它不被视为开发平台 - 它是一个桌面应用程序。当 MS-Access 首次出现时，许多人使用它构建应用程序。多用户功能不存在。最多四到五个用户就可以了。但我不会再追求更多。
Hosted on-line? Do you mean on the network? Technically it will work on a network but there is a reason MS-Access in not in Visual Studio - it is not considered a development platform - it is a desktop application. When MS-Access first hit the scene many people built applications using it. The multiuser functionality just is not there. Upto four or five users is ok. But I would not go for more.