如果Access能处理多用户的并发访问，那么是使用得什么机制呢？
希望数据库高手能回答，谢谢
12 个解决方案
#1
ACCESS能处理多用户操作，但是经常会出现问题，比如崩溃或锁死。
有时可以用修复工具恢复，有时会完全坏掉。
具体的机制就不清楚了，总之不稳定。
如果真要在多用户环境下用ACCESS，并发用户数控制在5个以内。多了问题更频繁。并要多做备份，经常压缩整理。
以上是说ACCESS97，ACCESS2000是不是好点，没有体会。
有时可以用修复工具恢复，有时会完全坏掉。
具体的机制就不清楚了，总之不稳定。
如果真要在多用户环境下用ACCESS，并发用户数控制在5个以内。多了问题更频繁。并要多做备份，经常压缩整理。
以上是说ACCESS97，ACCESS2000是不是好点，没有体会。
#2
我用的是Access2000，而且希望其能处理至少300个并发用户，所以用了一个中间层来专门和Access数据库打交道，这样是不是比每用户一个进程访问来得好些呢？
#3
如果你的中间层用了共享连接的话，实际连接到数据库的连接数就不会有300个。可能也可以承受。
但是对ACCESS不要报太大的希望。这样大的用户量，用NT+SQL SERVER可能都会有问题，别说ACCESS了。
但是对ACCESS不要报太大的希望。这样大的用户量，用NT+SQL SERVER可能都会有问题，别说ACCESS了。
#4
icevi,我是使用vb+Access的，使用ADO技术访问Access数据库的，看了您的意见后，我经过大量并发访问的测试，基本Access还没有出过什么问题（我用的是Access2000)，所以就更疑惑了，想请教一下您的具体实现经验，谢谢您！
#5
我以前接触过很多用户用ACCESS做数据库的，经常会数据库被破坏，打不开，或是索引关系丢了。更严重的数据库完全坏掉，送到MS也没搞好。这是实际情况，多数与多用户操作有关。
当然是说ACCESS 97，对于ACCESS 2000我没有观察过大量用户的使用情况。
当然是说ACCESS 97，对于ACCESS 2000我没有观察过大量用户的使用情况。
#6
to ztchen：请指教，我现在也是在做数据库，做C/S结构的，因为应用的数据量不大，所以觉得没必要采用SQL之类的大型数据库，想采用Access 2000。但我不知如何将数据库设置为数据库服务器来供用户联接（好象sql 一样)，我想问一下，你是如何实现的？是通过设置共享来实现多用户使用的吗？如果这样，好象不太安全吧？
#7
ArchieYao,这样当然很不安全，我使用ADO的OLEDB机制，在数据库结构和程序代码上做了大量控制，最头疼的是数据访问冲突的问题，这也是一个鱼和熊掌不可兼得的问题。不过此类问题好歹也是有办法解决的，但对于Access我也不熟，所以很想搞清楚其安全机制。至于实现连接，目前只有靠共享吧，毕竟mdb只是个文件，依靠设置权限及数据库密码应该还算凑合
#8
使用多线程对Access进行数据访问安全吗？，需不需要自己写代码协调线程呢？
#9
每一个线程去访数据库就和一个用户去访是一样的。现在你的并发访问能力是被数据库的并发访问能力限制了，在CLIENT端是没有办法的。按妞JJ说的对。
#10
不不不，我指的是Access数据库的安全性。因为考虑到要有大量的并发访问，所有就需要避免并发访问的情况，如设置信号量，使各个线程以协调的队列方式工作，避免同时去修改数据库。这些都可以用代码来实现。而我现在想问的就是如果我不做这些工作，Access数据库能为我做吗？其底层的访问机制是否能够自动协调？能达到什么极限呢？
#11
据我所知，ACCESS没有服务器的概念，也谈不上真正的C/S结构，所谓的多用户只是MDB文件的共享。所有的查询、更新操作都是在本地端完成的，比如当你查询SELECT * FROM MYTABLE WHERE COL1=1的时候，客户端会把这个表里的所有纪录（或者索引数据）通过网络传到客户端，客户端再对这些数据进行查询，更新也是一样的情况。在多用户、大数据量的情况下，ACCESS的应用会给网络带宽带来很大的压力。
从这些来看，ACCESS不能提供你说的自动协调工作机能。
从这些来看，ACCESS不能提供你说的自动协调工作机能。
#12
给分了
#1
ACCESS能处理多用户操作，但是经常会出现问题，比如崩溃或锁死。
有时可以用修复工具恢复，有时会完全坏掉。
具体的机制就不清楚了，总之不稳定。
如果真要在多用户环境下用ACCESS，并发用户数控制在5个以内。多了问题更频繁。并要多做备份，经常压缩整理。
以上是说ACCESS97，ACCESS2000是不是好点，没有体会。
有时可以用修复工具恢复，有时会完全坏掉。
具体的机制就不清楚了，总之不稳定。
如果真要在多用户环境下用ACCESS，并发用户数控制在5个以内。多了问题更频繁。并要多做备份，经常压缩整理。
以上是说ACCESS97，ACCESS2000是不是好点，没有体会。
#2
我用的是Access2000，而且希望其能处理至少300个并发用户，所以用了一个中间层来专门和Access数据库打交道，这样是不是比每用户一个进程访问来得好些呢？
#3
如果你的中间层用了共享连接的话，实际连接到数据库的连接数就不会有300个。可能也可以承受。
但是对ACCESS不要报太大的希望。这样大的用户量，用NT+SQL SERVER可能都会有问题，别说ACCESS了。
但是对ACCESS不要报太大的希望。这样大的用户量，用NT+SQL SERVER可能都会有问题，别说ACCESS了。
#4
icevi,我是使用vb+Access的，使用ADO技术访问Access数据库的，看了您的意见后，我经过大量并发访问的测试，基本Access还没有出过什么问题（我用的是Access2000)，所以就更疑惑了，想请教一下您的具体实现经验，谢谢您！
#5
我以前接触过很多用户用ACCESS做数据库的，经常会数据库被破坏，打不开，或是索引关系丢了。更严重的数据库完全坏掉，送到MS也没搞好。这是实际情况，多数与多用户操作有关。
当然是说ACCESS 97，对于ACCESS 2000我没有观察过大量用户的使用情况。
当然是说ACCESS 97，对于ACCESS 2000我没有观察过大量用户的使用情况。
#6
to ztchen：请指教，我现在也是在做数据库，做C/S结构的，因为应用的数据量不大，所以觉得没必要采用SQL之类的大型数据库，想采用Access 2000。但我不知如何将数据库设置为数据库服务器来供用户联接（好象sql 一样)，我想问一下，你是如何实现的？是通过设置共享来实现多用户使用的吗？如果这样，好象不太安全吧？
#7
ArchieYao,这样当然很不安全，我使用ADO的OLEDB机制，在数据库结构和程序代码上做了大量控制，最头疼的是数据访问冲突的问题，这也是一个鱼和熊掌不可兼得的问题。不过此类问题好歹也是有办法解决的，但对于Access我也不熟，所以很想搞清楚其安全机制。至于实现连接，目前只有靠共享吧，毕竟mdb只是个文件，依靠设置权限及数据库密码应该还算凑合
#8
使用多线程对Access进行数据访问安全吗？，需不需要自己写代码协调线程呢？
#9
每一个线程去访数据库就和一个用户去访是一样的。现在你的并发访问能力是被数据库的并发访问能力限制了，在CLIENT端是没有办法的。按妞JJ说的对。
#10
不不不，我指的是Access数据库的安全性。因为考虑到要有大量的并发访问，所有就需要避免并发访问的情况，如设置信号量，使各个线程以协调的队列方式工作，避免同时去修改数据库。这些都可以用代码来实现。而我现在想问的就是如果我不做这些工作，Access数据库能为我做吗？其底层的访问机制是否能够自动协调？能达到什么极限呢？
#11
据我所知，ACCESS没有服务器的概念，也谈不上真正的C/S结构，所谓的多用户只是MDB文件的共享。所有的查询、更新操作都是在本地端完成的，比如当你查询SELECT * FROM MYTABLE WHERE COL1=1的时候，客户端会把这个表里的所有纪录（或者索引数据）通过网络传到客户端，客户端再对这些数据进行查询，更新也是一样的情况。在多用户、大数据量的情况下，ACCESS的应用会给网络带宽带来很大的压力。
从这些来看，ACCESS不能提供你说的自动协调工作机能。
从这些来看，ACCESS不能提供你说的自动协调工作机能。
#12
给分了