Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
两个用户希望共享相同的数据库(最初是用MS Access编写的)，而不会因为一个MDB文件而相互冲突。
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
我使用它的迁移工具包(顺便说一下)将表从一个简单的MS Access数据库移到MySQL，并通过ODBC设置了访问这些表的访问。
So far, I've run into the following:
到目前为止，我遇到了以下问题:
- You can't insert/update/delete rows in a table without a primary key (no surprise there).
- 如果没有主键，就不能插入/更新/删除表中的行(这并不奇怪)。
- AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
- MS Access中的自动编号字段必须是主键，否则它们将在MySQL中作为整数列(natch，为什么不是PK?)
- The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
- 这些表被迁移到MySQL的InnoDB表类型，但是访问关系并没有成为MySQL外键约束。
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
一旦数据库被使用，我还能预料到其他问题吗?特别是当两个用户都在同一个表中工作时?
7 个解决方案
#1
14
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
我有一个类似的应用程序:MS Access前端到MySQL后端。这是如此巨大的痛苦，我最终写了一个Win32前端。从我的头顶开始，我遇到了以下问题:
- Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
- ODBC链接的开发似乎早已停止。到处都是各种不同的版本——非常令人困惑。ODBC链接不支持Unicode/UTF8，我记得它还存在其他问题(尽管一些问题可以通过仔细配置加以克服)。
- You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
- 您可能需要手动调整db模式，使其与MS访问兼容。我看到您已经找到了所需的代理键(例如。， int，主键):-)
- You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
- 您应该记住，可能需要使用传递查询来对MySQL数据库进行更复杂的SQL操作。
- Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
- 使用大量VBA时要小心，因为这样容易损坏前端文件。定期压缩数据库(使用主菜单、工具|数据库实用程序|压缩和恢复，或者类似的东西——我使用的是Dutch版本)，进行大量备份是必要的。
- Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
- 访问往往导致大量的网络流量。喜欢,真的大很多。我还没能找到解决办法。如果你想密切关注，建议使用网络监视器!
- Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
- Access坚持将布尔值存储为0/-1。IMHO, 0/+1更有意义，我相信这也是MySQL的默认方式。这不是一个大问题，但是如果你的复选框不起作用，你一定要检查一下。
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
一个可能的替代方案是将后端(与数据)放在共享驱动器上。我记得这是有充分记录的，也在帮助中。您可能想要了解一些关于将前端和后端分割成自动重新连接到后端的一般建议;我也可以给你发送更多的示例代码，或者在这里发布。
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
否则，您可能还需要考虑MS SQL。我没有这方面的经验，但是我认为它和MS Access一起工作得更好!
#2
16
I know this topic is not too fresh, but just some additional explanations:
我知道这个话题不是很新鲜，只是一些额外的解释:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
如果您想有效地使用MS Access，特别是在更大的多用户数据库中，请执行以下操作:
-
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
将MDB分割为前端应用程序和后端(仅针对数据)文件—您将有两个独立的MDB文件。
-
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
将具有数据和结构的所有表迁移到外部数据库。可以是:MySQL(效果很好,没有数据库大小限制,需要更多的技能,因为它不是女士的技术,但它是一个不错的选择在许多情况下,而且你可以扩展后端有更多的RAM和额外的cpu,所以一切取决于你的需求和硬件功能);甲骨文(如果你有足够的钱或者某种公司许可)或Oracle 10 g XE(如果这不是一个问题,4 GB的数据库的大小是有限的,它总是使用1 GB的RAM和CPU),MS SQL Server 2008(这是一个伟大的一对女士访问前端和MS SQL Server端在所有的情况下,但是你必须支付许可证!-优点是:紧密集成，这两种技术都是相同的供应商;MS SQL Server很容易同时保持高效)或Express edition(与Oracle XE类似——几乎相同的限制)。
-
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
将您的MS访问前端与后端数据库连接起来。如果您为后端选择了MS SQL Server，那么从MS Access使用该向导将非常简单。对于MySQL，您必须使用ODBC驱动程序(它很简单，而且工作得很好)。对于Oracle -请不要使用来自Microsoft的ODBC驱动程序。来自Oracle的这些工具可以更好地完成它们的工作(您可以比较通过Oracle ODBC和MS Oracle ODBC驱动程序从对Oracle的MS访问执行SQL查询所需的时间)。此时，您将拥有可靠的数据库后端和功能齐全的MS Access前端- MDB文件。
-
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
编译你的MDB前端趋向于MDE -它将给你很大的速度。此外，它是将MS访问应用程序分发给最终用户的唯一合理的形式。
-
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
对于日常工作-使用MDE文件与MS访问前端。以后的MS Access前端开发使用MDB文件。
-
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
不要使用编写不良的ActiveX组件来增强MS访问前端功能。最好自己写或者买合适的。
-
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
不要相信关于MS Access存在很多问题的神话——这是一个很好的产品，可以在5月份的时候帮助你。问题是，很多人认为这是一个玩具，或者认为MS Access一般来说很简单。通常他们自己会产生很多错误和问题，他们缺乏知识和经验。要想成功使用MS Access，了解这个工具是很重要的——这和其他任何技术都是一样的。
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
我可以告诉你，我正在使用非常高级的MS Access，它连接到MySQL后端，我非常满意(作为一个维护这个应用程序的开发人员)。我的朋友们，用户也很满意，因为他们对GUI(前端)、速度(MySQL)非常满意，他们对记录锁定和数据库性能没有任何问题。
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
此外，阅读大量关于良好实践和其他人经验的书籍是很重要的。我想说，在许多情况下，MS Access是一个很好的解决方案。我知道很多专门定制系统开始作为一种实验形式的私人MS Access数据库(MDB文件),然后进化:分裂女士访问(身边的前端,MDB -后端)最后:女士访问前端(身边)和“严肃”的数据库后端(主要是MS SQL Server和MySQL)。同样重要的是，您可以始终使用MS访问解决方案作为一个工作原型—您已经准备好在数据库中使用后端(假设是MySQL)，并且您可以重写前端，以便使用您所选择的技术(web解决方案?也许桌面c#应用程序-你需要什么!)
I hope I helped some of you considering the work with MS Access.
我希望我能帮助你们中的一些人考虑MS Access的工作。
Regards, Wawrzyn http://dcserwis.pl
问候,Wawrzyn http://dcserwis.pl
#3
3
Gareth Simpson opined:
加雷思·辛普森认为:
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
如果只有两个用户，那么如果您将.mdb放在共享驱动器上，那么访问应该没问题。
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
嗯,没有。没有一个多用户访问应用程序，每个用户都不应该有一个专用的前端副本。这意味着每个用户在他们的工作站上应该有一个MDB。为什么?因为前端的对象不能很好地共享(不像Jet数据表那样好，尽管在这个场景中没有使用MySQL作为后端)。
Gareth Simpson continued:
加雷思·辛普森继续说:
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
我认为推荐的最大并发用户是5，但有时我已经把它推到这一步，而且从来没有崩溃过。
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
不，这是完全错误的。MDB用户的理论限制是255。当然,这是不现实的,因为一旦你达到20个用户必须仔细计划你的访问应用程序工作得很好(虽然你需要做的事情在一个Access-to-Jet应用同样的事情你会做任何服务器数据库应用程序的效率,例如,检索最小的可用数据集)。
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
在这种情况下，由于每个用户都应该拥有前端MDB的单个副本，所以访问/Jet的多用户限制根本就不相关。
#4
2
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
我知道这并不能直接回答您的问题，但是有必要检查一下SQL Server 2005迁移工具。我从来没有使用过这个工具，但是使用SQL Server 2005 Express Edition看看是否存在与使用MySQL相同的问题
#5
2
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
别忘了在每条记录上都打上日期/时间戳。有时，access会认为“另一个用户已经更改或删除了记录”，并且不允许您进行更改!我费了好大的劲才发现这一点。
#6
1
In general, it depends :)
总的来说，这取决于:
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
当应用程序端刚刚通过表单更新数据时，我没有遇到很多问题。当同一行被多个用户更新时，您可以得到警告/错误;但是Access似乎一直在更新它的实时记录集。
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
如果Alice已经在使用记录365,Bob更新它，然后Alice尝试用她的更改更新它，那么问题就会发生。我记得，Alice会得到一个神秘的错误消息。如果您捕获这些错误，并且至少给用户一个更友好的错误消息，那么对用户来说会更容易。
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
当我通过记录集编辑VB代码中的记录时，我遇到了更多的问题，特别是当与在窗体上编辑相同数据相结合时。这并不一定是一个多用户问题;但是，您有几乎相同的情况，因为您有一个具有多个连接到相同数据的用户。
#7
0
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
如果只有两个用户，那么如果您将.mdb放在共享驱动器上，那么访问应该没问题。
Have you tried it first rather than just assume it will be a problem.
你有没有先试过，而不是想当然地认为会有问题。
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
我认为推荐的最大并发用户是5，但有时我已经把它推到这一步，而且从来没有崩溃过。
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.
另一方面，我曾经在一个用户环境(me)中使用Access作为MySQL的前端。这是一种非常不愉快的体验，我无法想象有两个用户会变得更好。
#1
14
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
我有一个类似的应用程序:MS Access前端到MySQL后端。这是如此巨大的痛苦，我最终写了一个Win32前端。从我的头顶开始，我遇到了以下问题:
- Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
- ODBC链接的开发似乎早已停止。到处都是各种不同的版本——非常令人困惑。ODBC链接不支持Unicode/UTF8，我记得它还存在其他问题(尽管一些问题可以通过仔细配置加以克服)。
- You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
- 您可能需要手动调整db模式，使其与MS访问兼容。我看到您已经找到了所需的代理键(例如。， int，主键):-)
- You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
- 您应该记住，可能需要使用传递查询来对MySQL数据库进行更复杂的SQL操作。
- Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
- 使用大量VBA时要小心，因为这样容易损坏前端文件。定期压缩数据库(使用主菜单、工具|数据库实用程序|压缩和恢复，或者类似的东西——我使用的是Dutch版本)，进行大量备份是必要的。
- Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
- 访问往往导致大量的网络流量。喜欢,真的大很多。我还没能找到解决办法。如果你想密切关注，建议使用网络监视器!
- Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
- Access坚持将布尔值存储为0/-1。IMHO, 0/+1更有意义，我相信这也是MySQL的默认方式。这不是一个大问题，但是如果你的复选框不起作用，你一定要检查一下。
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
一个可能的替代方案是将后端(与数据)放在共享驱动器上。我记得这是有充分记录的，也在帮助中。您可能想要了解一些关于将前端和后端分割成自动重新连接到后端的一般建议;我也可以给你发送更多的示例代码，或者在这里发布。
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
否则，您可能还需要考虑MS SQL。我没有这方面的经验，但是我认为它和MS Access一起工作得更好!
#2
16
I know this topic is not too fresh, but just some additional explanations:
我知道这个话题不是很新鲜，只是一些额外的解释:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
如果您想有效地使用MS Access，特别是在更大的多用户数据库中，请执行以下操作:
-
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
将MDB分割为前端应用程序和后端(仅针对数据)文件—您将有两个独立的MDB文件。
-
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
将具有数据和结构的所有表迁移到外部数据库。可以是:MySQL(效果很好,没有数据库大小限制,需要更多的技能,因为它不是女士的技术,但它是一个不错的选择在许多情况下,而且你可以扩展后端有更多的RAM和额外的cpu,所以一切取决于你的需求和硬件功能);甲骨文(如果你有足够的钱或者某种公司许可)或Oracle 10 g XE(如果这不是一个问题,4 GB的数据库的大小是有限的,它总是使用1 GB的RAM和CPU),MS SQL Server 2008(这是一个伟大的一对女士访问前端和MS SQL Server端在所有的情况下,但是你必须支付许可证!-优点是:紧密集成，这两种技术都是相同的供应商;MS SQL Server很容易同时保持高效)或Express edition(与Oracle XE类似——几乎相同的限制)。
-
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
将您的MS访问前端与后端数据库连接起来。如果您为后端选择了MS SQL Server，那么从MS Access使用该向导将非常简单。对于MySQL，您必须使用ODBC驱动程序(它很简单，而且工作得很好)。对于Oracle -请不要使用来自Microsoft的ODBC驱动程序。来自Oracle的这些工具可以更好地完成它们的工作(您可以比较通过Oracle ODBC和MS Oracle ODBC驱动程序从对Oracle的MS访问执行SQL查询所需的时间)。此时，您将拥有可靠的数据库后端和功能齐全的MS Access前端- MDB文件。
-
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
编译你的MDB前端趋向于MDE -它将给你很大的速度。此外，它是将MS访问应用程序分发给最终用户的唯一合理的形式。
-
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
对于日常工作-使用MDE文件与MS访问前端。以后的MS Access前端开发使用MDB文件。
-
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
不要使用编写不良的ActiveX组件来增强MS访问前端功能。最好自己写或者买合适的。
-
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
不要相信关于MS Access存在很多问题的神话——这是一个很好的产品，可以在5月份的时候帮助你。问题是，很多人认为这是一个玩具，或者认为MS Access一般来说很简单。通常他们自己会产生很多错误和问题，他们缺乏知识和经验。要想成功使用MS Access，了解这个工具是很重要的——这和其他任何技术都是一样的。
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
我可以告诉你，我正在使用非常高级的MS Access，它连接到MySQL后端，我非常满意(作为一个维护这个应用程序的开发人员)。我的朋友们，用户也很满意，因为他们对GUI(前端)、速度(MySQL)非常满意，他们对记录锁定和数据库性能没有任何问题。
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
此外，阅读大量关于良好实践和其他人经验的书籍是很重要的。我想说，在许多情况下，MS Access是一个很好的解决方案。我知道很多专门定制系统开始作为一种实验形式的私人MS Access数据库(MDB文件),然后进化:分裂女士访问(身边的前端,MDB -后端)最后:女士访问前端(身边)和“严肃”的数据库后端(主要是MS SQL Server和MySQL)。同样重要的是，您可以始终使用MS访问解决方案作为一个工作原型—您已经准备好在数据库中使用后端(假设是MySQL)，并且您可以重写前端，以便使用您所选择的技术(web解决方案?也许桌面c#应用程序-你需要什么!)
I hope I helped some of you considering the work with MS Access.
我希望我能帮助你们中的一些人考虑MS Access的工作。
Regards, Wawrzyn http://dcserwis.pl
问候,Wawrzyn http://dcserwis.pl
#3
3
Gareth Simpson opined:
加雷思·辛普森认为:
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
如果只有两个用户，那么如果您将.mdb放在共享驱动器上，那么访问应该没问题。
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
嗯,没有。没有一个多用户访问应用程序，每个用户都不应该有一个专用的前端副本。这意味着每个用户在他们的工作站上应该有一个MDB。为什么?因为前端的对象不能很好地共享(不像Jet数据表那样好，尽管在这个场景中没有使用MySQL作为后端)。
Gareth Simpson continued:
加雷思·辛普森继续说:
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
我认为推荐的最大并发用户是5，但有时我已经把它推到这一步，而且从来没有崩溃过。
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
不，这是完全错误的。MDB用户的理论限制是255。当然,这是不现实的,因为一旦你达到20个用户必须仔细计划你的访问应用程序工作得很好(虽然你需要做的事情在一个Access-to-Jet应用同样的事情你会做任何服务器数据库应用程序的效率,例如,检索最小的可用数据集)。
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
在这种情况下，由于每个用户都应该拥有前端MDB的单个副本，所以访问/Jet的多用户限制根本就不相关。
#4
2
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
我知道这并不能直接回答您的问题，但是有必要检查一下SQL Server 2005迁移工具。我从来没有使用过这个工具，但是使用SQL Server 2005 Express Edition看看是否存在与使用MySQL相同的问题
#5
2
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
别忘了在每条记录上都打上日期/时间戳。有时，access会认为“另一个用户已经更改或删除了记录”，并且不允许您进行更改!我费了好大的劲才发现这一点。
#6
1
In general, it depends :)
总的来说，这取决于:
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
当应用程序端刚刚通过表单更新数据时，我没有遇到很多问题。当同一行被多个用户更新时，您可以得到警告/错误;但是Access似乎一直在更新它的实时记录集。
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
如果Alice已经在使用记录365,Bob更新它，然后Alice尝试用她的更改更新它，那么问题就会发生。我记得，Alice会得到一个神秘的错误消息。如果您捕获这些错误，并且至少给用户一个更友好的错误消息，那么对用户来说会更容易。
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
当我通过记录集编辑VB代码中的记录时，我遇到了更多的问题，特别是当与在窗体上编辑相同数据相结合时。这并不一定是一个多用户问题;但是，您有几乎相同的情况，因为您有一个具有多个连接到相同数据的用户。
#7
0
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
如果只有两个用户，那么如果您将.mdb放在共享驱动器上，那么访问应该没问题。
Have you tried it first rather than just assume it will be a problem.
你有没有先试过，而不是想当然地认为会有问题。
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
我认为推荐的最大并发用户是5，但有时我已经把它推到这一步，而且从来没有崩溃过。
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.
另一方面，我曾经在一个用户环境(me)中使用Access作为MySQL的前端。这是一种非常不愉快的体验，我无法想象有两个用户会变得更好。