I am having a real problem at work with a highly ingrained developer obsessed with ms access. Users moan about random crashes, locking errors, freeze's, the application slowing down (especially in 2007) but seem to be very resistant to moving it. Most of the time they blame the computer and can't be convinced it's the fact its a mdb sat on a network drive and nothing to do with the hardware sat in front of them which is brand new.
我在工作中遇到了一个真正的问题，一个根深蒂固的开发人员沉迷于ms access。用户抱怨随机崩溃，锁定错误，冻结，应用程序慢下来(特别是在2007年)，但似乎非常抗拒移动它。大多数时候，他们都指责电脑，无法相信它的a mdb位于网络驱动器上，与摆在他们面前的硬件毫无关系，这是全新的。
There is a front end vb program hanging off it but I don't think it would take more than a couple of weeks to adjust, infact I would probably re-write it as it has year on year messy code from a previous developer.
有一个前端vb程序挂起了它，但我不认为它需要超过几个星期的时间来调整，事实上，我可能会重新编写它，因为它每年都有来自前一个开发人员的混乱代码。
What are my best arguments to convince them we need to move it?
我最好的论据是什么，让他们相信我们需要移动它?
Does anyone else have similar problems with developers stuck in their ways?
有没有人遇到过同样的问题?
15 个解决方案
#1
11
how about the random, crashes, locking errors, freeze's, slow downs (sic).
随机的，崩溃的，锁定错误，冻结的，慢下来的(原文如此)。
A quick search on the web finds some useful materials:
在网上快速搜索一下，你会发现一些有用的资料:
- Best Practices When Using Microsoft Office Access 2003 in a Multi-user Environment - if the changes here can't be implemented, or would effectively take a rewrite, then that is good ammunition for doing it right.
- 在多用户环境中使用microsoftoffice Access 2003的最佳实践——如果这里的更改不能实现，或者需要进行有效的重写，那么这就是正确操作的好弹药。
- SQL Server vs MS Access - pay special attention to feature limits. Eg You can only have 32,000 objects in an access DB. Caveat: though it says 255 concurrent users, and that is probably a technical limitation, the practical limitation is really MUCH lower.
- SQL Server vs MS Access——特别注意特性限制。一个访问数据库中只能有32,000个对象。注意:虽然它说255个并发用户，这可能是技术上的限制，但实际的限制要低得多。
It's hard to convince people that are not willing to learn and are not open to new ideas. You can go on about speed issues, concurrency issues, security problems.. but ultimately, some people will just never listen. Go over their heads. Rewrite it in tools from this decade and show them up. Refuse to be involved with the project and further. I don't know what the political situation is, but technically, MS access is wrong for what you are doing, from what you've described.
很难说服那些不愿意学习、不愿意接受新思想的人。您可以继续讨论速度问题、并发问题和安全问题。但归根结底，有些人永远不会倾听。在他们的头上去。在这十年的工具中重写它并显示它们。拒绝参与该项目及进一步。我不知道政治形势如何，但从技术上讲，access女士所做的一切，从你所描述的来看，都是错误的。
#2
3
come in on a weekend, copy the database to sql server, change the app's connect-strings to sql server, retest the application, then uninstall ms-access...everywhere.
周末来，把数据库复制到sql server，把应用程序的连接字符串更改为sql server，重新测试应用程序，然后卸载ms-access……
then don't say anything about it, let him think that the problems 'fixed themselves' and that the users are still using ms-access
那就别再说什么了，让他觉得问题“自己解决了”，用户还在使用ms-access
#3
3
To me it depends on how many concurrent users you have and how big the database is. If you have more than 5 concurrent users then you should be thinking about a database server. The network traffic starts to get out of hand and with each concurrent user you add it just gets worse.
对我来说，这取决于有多少并发用户以及数据库有多大。如果您有超过5个并发用户，那么您应该考虑一个数据库服务器。网络流量开始失控，每一个并发用户都变得更糟。
I have created reliable access based systems for years. If you are having random crashes, locking issues, and slow downs then you aren't doing something right. I typically will have an mda local with the mdb on the network when creating an app in access. To have good performance it's key to have the proper indexes and queries optimized for getting just the data you need. Whether using a separate app, access, or some app running against sql server you need to actively handle record locking properly. You can't just blindly let access lock your records.
多年来，我创建了基于可靠访问的系统。如果你有随机的崩溃，锁定问题，和慢下来，那么你就没有做对的事情。在创建访问中的应用程序时，我通常会在网络上有一个带有mdb的mda本地版本。要有良好的性能，关键是要有适当的索引和查询，以获得所需的数据。无论是使用单独的应用程序、访问，还是一些运行在sql server上的应用程序，您都需要积极地处理记录锁定。你不能盲目地让access锁住你的记录。
#4
3
Forget the arguments about DB Size, it is an uninformed reason to shift to a client-server platform in 90% of the cases I hear it brought up.
忘记了关于DB大小的争论，在我所听到的90%的案例中，这是一个不知情的原因，转移到客户机-服务器平台。
Your best arguments are based on features explained at a low tech level: (1) You can backup and perform maintenance on the DB without kicking out the users (which introduces costly downtime).
您最好的参数是基于在低技术级别上解释的特性:(1)您可以备份和执行DB，而不需要赶走用户(这会导致代价高昂的停机时间)。
(2) Faster recovery if data is accidentally deleted/mangled or corrupted. Again, less risk and less downtime. This is always a good foundation for a business case.
(2)如果数据被意外删除、损坏或损坏，恢复速度更快。同样，风险更小，停机时间更短。对于商业案例来说，这是一个很好的基础。
(3) If (and only if) you anticipate the need to scale quite a bit, the upgrade will better allow that.
(3)如果(且仅当)您预期需要扩展到相当大的范围，升级将更好地允许这一点。
(4) If you need to run automated jobs/updates, SQL can do this much more elegantly.
(4)如果您需要运行自动作业/更新，SQL可以更优雅地执行此操作。
Remember the contra-indications for SQL, it is easy to get on your technical high-horse about this platform versus that, but you have to balance the benefits against the costs. SQL is a Helluva lot more expensive to maintain as it requires dedicated hardware, expensive licenses (Server OS and DB) and usually at least a part time DBA that is going to cost you a bare minimum of $75K (if you get luck AND work out of Podunk Iowa).
还记得SQL的对比指示吗?在这个平台上，你很容易就能找到你的技术优势，但是你必须权衡利弊。SQL维护起来要贵得多，因为它需要专用的硬件、昂贵的许可证(服务器OS和DB)，通常还需要至少一名兼职DBA，至少要花费75K美元(如果你运气好的话，在Podunk Iowa工作的话)。
#5
2
The best possible advice I can give you is to make sure that you have a good attitude and are known as someone who does quality work and gets things done. It sounds like you don't have any control in the situation so what you need is influence.
我能给你的最好的建议是确保你有一个好的态度，并且被认为是一个做高质量工作和完成事情的人。听起来你无法控制局面，所以你需要的是影响力。
Find a way to solve a problem (probably a different one that is less threatening to the people involved) in the way you are suggesting. Make it work blindingly fast and flawlessly. Make it work so well that people start asking for you when they need something done. Get it done quickly, which you should be able to do because you'll be using the right tools for the job.
找到一种解决问题的方法(可能是另一种对涉及到的人的威胁较小的问题)，就像你建议的那样。让它快速而完美地工作。让它工作得很好，当人们需要做某事时，他们就开始找你。尽快完成它，这是你应该能够做到的，因为你将使用正确的工具完成这项工作。
Be a good person to work with, not the PITA that knows how everyone else should write their code. Be able to give an answer for what you might do differently and why, but don't automatically assume that your ideas are always the best. Maybe there are trade-offs that you don't know about -- no money in the budget for the extra CALs, we have this other app that needs to be done first. This doesn't sound like your situation, but looking for opportunities to understand before making constructive criticisms can go a long way to helping people be receptive.
做一个好共事的人，而不是那些知道别人应该如何写代码的人。能够给出一个答案，你可能会做出不同的选择，但不要想当然地认为你的想法总是最好的。也许有一些你不知道的权衡——没有多余的CALs的预算，我们有另一个需要先做的应用。这听起来不像是你的处境，但是在提出建设性的批评之前寻找理解的机会可以帮助人们接受。
The other thing is that this probably has nothing to do with the technical aspects of the situation and everything to do with the insecurities of the other developer. "This is all I know. If we change it, I won't understand it and then where will I be." Look for ways to help the other guy grow -- when he's having a problem, find resources that will help him develop good technical solutions. Suggest that everyone in your department get some training in new technologies. Who knows, one good SQL Server course and the guy could become the SQL Server evangelist in the organization because now THAT'S what he knows.
另一件事是，这可能与情况的技术方面无关，而与其他开发人员的不安全感有关。这就是我所知道的一切。如果我们改变它，我不会理解它，然后我将在哪里寻找帮助他人成长的方法——当他遇到问题时，找一些能帮助他开发好的技术解决方案的资源。建议你部门的每个人都接受一些新技术的培训。谁知道呢，一个好的SQL Server课程，他就能成为组织里的SQL Server布道者，因为现在他知道了。
Lastly, know when to cut your losses, so to speak. If you find that you're not able to do anything about the situation, don't add to the complaining. Move on to something that you can control and do it as well as you can. Maybe in the future you'll be in a position that you do have control or influence in the situation and can do something about it. If you find that you're in a company that's more dysfunctional than most, find a way to move on to a place where the environment is better.
最后，可以说，知道什么时候减少损失。如果你发现你对这种情况无能为力，不要再抱怨了。继续做一些你能控制的事情，并尽可能地做好。也许在未来，你将处于一个你可以控制或影响的位置，并且可以做些什么。如果你发现你所在的公司比大多数人都更不正常，那就找一种方法，去一个环境更好的地方。
#6
2
It is possible, and actually fairly easy, to convert an Access database to having the tables/views in SQL Server while still using the Access app as a front-end.
在使用Access app作为前端的同时，将Access数据库转换为SQL Server中的表/视图是可能的，而且实际上相当容易。
From there, your Access-obsessed developer can still have fun with all that VBA code. Meanwhile, on the back-end, you add indexes and such to speed everything up. Maybe someday you get lucky, and he asks about stored procedures. Then, the app is just a front-end, and who cares what it's written in? Your data is safe in SQL Server.
从这里开始，痴迷于访问的开发人员仍然可以享受所有VBA代码。同时，在后端，添加索引等以加快一切。也许有一天你走运了，他问你存储过程。那么，这个应用程序只是一个前端，谁在乎它写的是什么呢?您的数据在SQL Server中是安全的。
It is possible for you to do this yourself, but just leave the production app ALOOOOOOOOOOOONE. Take a copy, and convert that copy. Then, host it for a couple of users to TEST drive .. make your version of the Access app show "TEST APP" in big red letters. If your developer asks what you're doing, you can say the truth -- you are testing to see if converting only the tables/views might be of some help to the overall app.
你可以自己做这个，但是只需要离开生产应用程序。拿一份拷贝，然后转换它。然后，将它托管给几个用户来测试驱动器。让你的访问应用程序的版本用红色大字显示“测试应用”。如果开发人员问你在做什么，你可以说实话——你在测试，看仅仅转换表/视图是否对整个应用程序有所帮助。
This way, you get the best of both worlds, keep your developer happy, make the users happier (hopefully), and if you play it right, your bosses will know that you handled a knotty personnel issue with your technological prowess and your maturity.
通过这种方式，您可以充分利用这两个方面，让您的开发人员感到高兴，让用户感到高兴(希望如此)，如果您操作得当，您的老板将知道您处理了一个棘手的人事问题，您的技术能力和您的成熟度。
#7
1
I once had similar problems with someone I would not hesistate to call a complete idiot.
我曾经和一个我不愿称其为完全白痴的人有过类似的问题。
It was not possible to convince them of the issues with access. In the end it was easier to force the issue than do it "nicely", cruel to be kind.
不可能使他们相信有关访问的问题。最后，解决这个问题比“好”、“仁慈”更容易。
#8
1
If they resist then you can always go above their head. Management must be aware of crashes and stability related issues. Present a plan to them to improve stability and they are likely to at least listen. They will probably then want a meeting with all developers to discuss so go into it armed with plenty of ammo.
如果他们拒绝了，你就可以超越他们的头。管理人员必须了解崩溃和稳定性相关的问题。向他们提出一个改善稳定性的计划，他们可能至少会听取他们的意见。他们可能会希望与所有开发人员开会讨论，所以带着足够的弹药进入。
#9
1
More than "How to convince them", let's talk about "How to do it without anybody noticing"!
除了“如何说服他们”，让我们来谈谈“如何在没有人注意的情况下做到这一点”!
First of all I advice you not to mix together the code optimisation issue and the SQL server one. Do not give users a chance to complain about SQL while bugs are related to something else.
首先，我建议您不要将代码优化问题和SQL server问题混为一谈。不要给用户一个机会去抱怨SQL，而bug与其他事情有关。
If your code is really unbearable, rewrite the app before switching to SQL, keeping in mind the following points to make the final transition to SQL Server completely transparent for final users.
如果您的代码实在难以忍受，那么在切换到SQL之前重写应用程序，记住以下几点，以便最终向SQL Server的转换对最终用户完全透明。
This is what we did 18 months ago, and I am sure we still have users thinking our database is Access:
这是我们18个月前所做的，我确信我们的用户仍然认为我们的数据库是Access:
- Export current access database to SQL through available Wizard in access for testing purposes (many problems might occur, and you could need another tool such as the one proposed here).
- 通过可用的向导将当前的访问数据库导出到SQL以供测试使用(可能会出现许多问题，您可能需要另一个工具，如本文中建议的工具)。
- Create a unique connection object at the application level, so that you can freely switch from Access to SQL at any time (at development level, you can even add an input box at startup to ask which connection to use). We chose an ADODB connection object, but it will also work with ODBC connection.
- 在应用程序级别创建一个唯一的连接对象，以便您可以在任何时候*地从访问切换到SQL(在开发级别，您甚至可以在启动时添加一个输入框来询问使用哪个连接)。我们选择了ADODB连接对象，但它也可以使用ODBC连接。
- In case you use SQL syntax to update tables, make sure that all SELECTs, INSERTs, UPDATEs and DELETEs make use of this connection. In case you use recordset, make sure that all of them use this connection at opening time.
- 如果您使用SQL语法更新表，请确保所有的选择、插入、更新和删除都使用此连接。如果您使用记录集，请确保所有的记录集都在打开时使用此连接。
- When needed, update all connexion specific code by adding a "SELECT CASE"
type_Of_TheConnexionoptions - 需要时，通过添加“选择案例”type_Of_TheConnexion选项更新所有connexion特定代码
- Switch to SQL connection ..and debug till you're done!
- 切换到SQL连接。调试，直到你完成!
The problems you will find are mainly linked to SQL syntax, where MSSQL uses ' instead of " and # as separators. Date format is also an issue, where standard SQL format is 'YYYYMMDD' while MS-Access format depends on computer locals (beware of conversions from date to string!) and is stored as "YYYY-MM-DD" (if I remember ...). Boolean in SQL are 0 and 1, while they are True/False or 0/-1 in Access ...
您将发现的问题主要与SQL语法相关，其中MSSQL使用“而不是”和#作为分隔符。日期格式也是一个问题，标准的SQL格式是“yyyyymmdd”，而MS-Access格式依赖于计算机局部变量(注意从日期到字符串的转换)，并存储为“yyyyyyy - mm - dd”(如果我记得…)。SQL中的布尔值为0和1，而访问中它们是True/False或0/-1。
Test, update code, and when you are ok, make a new data transfer, lock your app on the SQL connection, and distribute a new runtime.
测试、更新代码，当您没问题时，进行新的数据传输，在SQL连接上锁定应用程序，并分发新的运行时。
#10
1
It depends on the type of application and data load of your database but Access is quite efficient, even over the network.
Depending on the amount of data your users deal with you could easily scale up to a 100 users on a network just using a from and back-end Access database.
它取决于应用程序的类型和数据库的数据负载，但是访问是非常有效的，即使是通过网络。根据您的用户处理的数据量，只需使用from和后端访问数据库，就可以轻松地扩展到网络上的100个用户。
Looks like in your case a rewrite may be in order. If your application is data-centric if doesn't make much sense to develop it in VB6: the tools given by Access are much better than anything you'd be able to make, especially when considering Access 2007.
在您的例子中，重写可能是正确的。如果您的应用程序是以数据为中心的，那么在VB6中开发它就没有多大意义了:Access提供的工具要比您能够提供的任何工具都好得多，特别是在考虑Access 2007时。
Upsizing to SQL Server is only really required if you're getting into issues of:
只有在遇到以下问题时才真正需要对SQL Server进行升级:
-
Security:
you need to make sure that only the rights users can access data. You can do your own security in Access, but it's never going to be as strong as SQL Server. - 安全性:您需要确保只有权限用户才能访问数据。您可以在访问中实现自己的安全性，但它永远不会像SQL Server那样强大。
-
Scalability:
you're dealing with lots of data and complex queries or a lot of users and it would be better to have dedicated hardware to handle the load for the clients. The issue with this though is that while removing the pressure from the less-capable clients machines, you're adding a lot more to the server. - 可伸缩性:您正在处理大量的数据和复杂的查询或大量的用户，最好有专门的硬件来处理客户端的负载。但是，问题是，尽管从性能较差的客户端机器上消除了压力，但您向服务器添加的内容要多得多。
-
Integrity:
With the back-end database being just a file that needs R/W access for all connected clients, there's always the possibility that someone is going to do something bad or that a client may crash and leave the database corrupted. - 完整性:后端数据库只是一个文件，需要对所有连接的客户端进行R/W访问，因此总有可能有人做了坏事，或者客户端可能崩溃并导致数据库损坏。
If your number of users is average (I'd say 30), then there's probably no real need to upscale:
如果你的用户数量是平均的(我认为是30人)，那么你可能没有真正的需要去升级:
- Use MS Access 2007 to develop your application, then just use the MS Access 2007 Runtime (it's free!) on all client machines to get a more modern user interface (uses the Ribbon and has lots of UI enhancements over previous versions).
You can't be the cheapness of that solution : you only need full retail version of MS Access and all the rest is free, regardess of the number of users! - 使用MS Access 2007来开发应用程序，然后在所有客户端机器上使用MS Access 2007运行时(它是免费的!)来获得更现代的用户界面(使用Ribbon，与以前的版本相比有很多UI增强)。你不可能便宜的解决方案:你只需要完整的零售版本的MS Access，其余的都是免费的，不管用户的数量!
- Don't think that moving to SQL Server is going to improve performance of your queries: MS Access often does a better job of optimizing the queries for you (it knows what needs to be displayed and does lots of caching and optimization).
- 不要认为迁移到SQL Server将提高查询的性能:MS Access在优化查询方面通常做得更好(它知道需要显示什么，并进行大量缓存和优化)。
- Make sure you only edit small amounts of data at any one time (don't use dynaset queries just to display vast amounts of data in a datasheet; use a snapshot instead and open a detail form that only contains the data to edit when necessary.
- 确保每次只编辑少量数据(不要使用dynaset查询，只需要在数据表中显示大量数据;使用快照，打开一个细节表单，其中只包含需要编辑的数据。
- Cache complex queries locally.
Built some caching mechanism that leaves a copy of the results of a complex query on the local machine. The gain in performance is pretty amazing and if the query doens't change much (for instance a log of stock operations) you can just persist the complex/big query locally and append new records as necessary. - 在本地缓存复杂查询。构建了一些缓存机制，在本地机器上留下复杂查询结果的副本。性能的提高非常惊人，如果查询变化不大(例如股票操作日志)，您可以在本地持久化复杂/大型查询，并根据需要附加新记录。
There is so much more to say.
还有很多话要说。
Bottom line is: you may be looking at a rewrite, but don't dismiss Access as the solution because your current application was poorly written.
底线是:您可能正在查看重写，但是不要因为当前应用程序编写得很糟糕而将访问排除为解决方案。
#11
0
Try bechmarking and showing the stats to him
试试做标记，给他看统计数据
#12
0
Here is an in depth list of reasons why you might consider moving straight from Microsoft:
以下是你可能会考虑直接从微软跳槽的原因:
http://msdn.microsoft.com/en-us/library/aa902657(SQL.80).aspx
http://msdn.microsoft.com/en-us/library/aa902657(SQL.80). aspx
#13
0
Making people change can sometimes be a real pain in the butt.
让人们改变有时会让人痛苦。
I would have to say the main argument would have stability and speed, but of course like you have said they already know this a still won't move.
Another thing to try would be to show them the power of LINQ to SQL and how much cleaner it would make your application. Like Daniel Silveira said you could try and throw a couple of stats there way and see if they are convinced.
我不得不说主要的论点会有稳定性和速度，但是当然像你说的他们已经知道a仍然不会移动。另一件需要尝试的事情是向他们展示LINQ对SQL的强大功能，以及它将使您的应用程序变得多么干净。就像丹尼尔·西尔维拉说的那样，你可以试着投一些数据，看看他们是否信服。
We have a app build using MS access as a back end and I can't wait till we get our new SQL server so I can move everything to that.
我们有一个应用程序构建，使用MS access作为后端，我不能等到我们得到新的SQL server，这样我就可以移动所有的东西。
#14
0
You could show him the perf results comparing the two, but if he's really set in his ways and refuses to change, there isn't much you can do except force him somehow.
你可以给他看比较这两个结果的结果，但是如果他真的固守自己的方式并且拒绝改变，你除了以某种方式强迫他之外没有什么可以做的。
If you're his boss then just force him to change it to use SQL. If not, then convince your boss to force the change by showing him the perf results and explain it'll fix the issues you're having.
如果你是他的老板，那就强迫他修改为使用SQL。如果没有，那就向你的老板展示你的绩效考核结果，并向他解释这能解决你的问题，以此来说服他做出改变。
#15
0
Errr, leave the team? You seem to be working with the totally wrong set of people. Now, if the team IS your company, then you are working with the wrong company.
哦,离开团队了吗?你似乎在和完全错误的人打交道。现在，如果团队是你的公司，那么你是在错误的公司工作。
Of course once you leave the company, you could tell your clients that you could solve the network problems on their own and make them leave the company as well. Then give them an improved system that works on SQL Server Express.
当然，一旦你离开公司，你可以告诉你的客户你可以自己解决网络问题，让他们也离开公司。然后为他们提供一个在SQL Server Express上工作的改进系统。
#1
11
how about the random, crashes, locking errors, freeze's, slow downs (sic).
随机的，崩溃的，锁定错误，冻结的，慢下来的(原文如此)。
A quick search on the web finds some useful materials:
在网上快速搜索一下，你会发现一些有用的资料:
- Best Practices When Using Microsoft Office Access 2003 in a Multi-user Environment - if the changes here can't be implemented, or would effectively take a rewrite, then that is good ammunition for doing it right.
- 在多用户环境中使用microsoftoffice Access 2003的最佳实践——如果这里的更改不能实现，或者需要进行有效的重写，那么这就是正确操作的好弹药。
- SQL Server vs MS Access - pay special attention to feature limits. Eg You can only have 32,000 objects in an access DB. Caveat: though it says 255 concurrent users, and that is probably a technical limitation, the practical limitation is really MUCH lower.
- SQL Server vs MS Access——特别注意特性限制。一个访问数据库中只能有32,000个对象。注意:虽然它说255个并发用户，这可能是技术上的限制，但实际的限制要低得多。
It's hard to convince people that are not willing to learn and are not open to new ideas. You can go on about speed issues, concurrency issues, security problems.. but ultimately, some people will just never listen. Go over their heads. Rewrite it in tools from this decade and show them up. Refuse to be involved with the project and further. I don't know what the political situation is, but technically, MS access is wrong for what you are doing, from what you've described.
很难说服那些不愿意学习、不愿意接受新思想的人。您可以继续讨论速度问题、并发问题和安全问题。但归根结底，有些人永远不会倾听。在他们的头上去。在这十年的工具中重写它并显示它们。拒绝参与该项目及进一步。我不知道政治形势如何，但从技术上讲，access女士所做的一切，从你所描述的来看，都是错误的。
#2
3
come in on a weekend, copy the database to sql server, change the app's connect-strings to sql server, retest the application, then uninstall ms-access...everywhere.
周末来，把数据库复制到sql server，把应用程序的连接字符串更改为sql server，重新测试应用程序，然后卸载ms-access……
then don't say anything about it, let him think that the problems 'fixed themselves' and that the users are still using ms-access
那就别再说什么了，让他觉得问题“自己解决了”，用户还在使用ms-access
#3
3
To me it depends on how many concurrent users you have and how big the database is. If you have more than 5 concurrent users then you should be thinking about a database server. The network traffic starts to get out of hand and with each concurrent user you add it just gets worse.
对我来说，这取决于有多少并发用户以及数据库有多大。如果您有超过5个并发用户，那么您应该考虑一个数据库服务器。网络流量开始失控，每一个并发用户都变得更糟。
I have created reliable access based systems for years. If you are having random crashes, locking issues, and slow downs then you aren't doing something right. I typically will have an mda local with the mdb on the network when creating an app in access. To have good performance it's key to have the proper indexes and queries optimized for getting just the data you need. Whether using a separate app, access, or some app running against sql server you need to actively handle record locking properly. You can't just blindly let access lock your records.
多年来，我创建了基于可靠访问的系统。如果你有随机的崩溃，锁定问题，和慢下来，那么你就没有做对的事情。在创建访问中的应用程序时，我通常会在网络上有一个带有mdb的mda本地版本。要有良好的性能，关键是要有适当的索引和查询，以获得所需的数据。无论是使用单独的应用程序、访问，还是一些运行在sql server上的应用程序，您都需要积极地处理记录锁定。你不能盲目地让access锁住你的记录。
#4
3
Forget the arguments about DB Size, it is an uninformed reason to shift to a client-server platform in 90% of the cases I hear it brought up.
忘记了关于DB大小的争论，在我所听到的90%的案例中，这是一个不知情的原因，转移到客户机-服务器平台。
Your best arguments are based on features explained at a low tech level: (1) You can backup and perform maintenance on the DB without kicking out the users (which introduces costly downtime).
您最好的参数是基于在低技术级别上解释的特性:(1)您可以备份和执行DB，而不需要赶走用户(这会导致代价高昂的停机时间)。
(2) Faster recovery if data is accidentally deleted/mangled or corrupted. Again, less risk and less downtime. This is always a good foundation for a business case.
(2)如果数据被意外删除、损坏或损坏，恢复速度更快。同样，风险更小，停机时间更短。对于商业案例来说，这是一个很好的基础。
(3) If (and only if) you anticipate the need to scale quite a bit, the upgrade will better allow that.
(3)如果(且仅当)您预期需要扩展到相当大的范围，升级将更好地允许这一点。
(4) If you need to run automated jobs/updates, SQL can do this much more elegantly.
(4)如果您需要运行自动作业/更新，SQL可以更优雅地执行此操作。
Remember the contra-indications for SQL, it is easy to get on your technical high-horse about this platform versus that, but you have to balance the benefits against the costs. SQL is a Helluva lot more expensive to maintain as it requires dedicated hardware, expensive licenses (Server OS and DB) and usually at least a part time DBA that is going to cost you a bare minimum of $75K (if you get luck AND work out of Podunk Iowa).
还记得SQL的对比指示吗?在这个平台上，你很容易就能找到你的技术优势，但是你必须权衡利弊。SQL维护起来要贵得多，因为它需要专用的硬件、昂贵的许可证(服务器OS和DB)，通常还需要至少一名兼职DBA，至少要花费75K美元(如果你运气好的话，在Podunk Iowa工作的话)。
#5
2
The best possible advice I can give you is to make sure that you have a good attitude and are known as someone who does quality work and gets things done. It sounds like you don't have any control in the situation so what you need is influence.
我能给你的最好的建议是确保你有一个好的态度，并且被认为是一个做高质量工作和完成事情的人。听起来你无法控制局面，所以你需要的是影响力。
Find a way to solve a problem (probably a different one that is less threatening to the people involved) in the way you are suggesting. Make it work blindingly fast and flawlessly. Make it work so well that people start asking for you when they need something done. Get it done quickly, which you should be able to do because you'll be using the right tools for the job.
找到一种解决问题的方法(可能是另一种对涉及到的人的威胁较小的问题)，就像你建议的那样。让它快速而完美地工作。让它工作得很好，当人们需要做某事时，他们就开始找你。尽快完成它，这是你应该能够做到的，因为你将使用正确的工具完成这项工作。
Be a good person to work with, not the PITA that knows how everyone else should write their code. Be able to give an answer for what you might do differently and why, but don't automatically assume that your ideas are always the best. Maybe there are trade-offs that you don't know about -- no money in the budget for the extra CALs, we have this other app that needs to be done first. This doesn't sound like your situation, but looking for opportunities to understand before making constructive criticisms can go a long way to helping people be receptive.
做一个好共事的人，而不是那些知道别人应该如何写代码的人。能够给出一个答案，你可能会做出不同的选择，但不要想当然地认为你的想法总是最好的。也许有一些你不知道的权衡——没有多余的CALs的预算，我们有另一个需要先做的应用。这听起来不像是你的处境，但是在提出建设性的批评之前寻找理解的机会可以帮助人们接受。
The other thing is that this probably has nothing to do with the technical aspects of the situation and everything to do with the insecurities of the other developer. "This is all I know. If we change it, I won't understand it and then where will I be." Look for ways to help the other guy grow -- when he's having a problem, find resources that will help him develop good technical solutions. Suggest that everyone in your department get some training in new technologies. Who knows, one good SQL Server course and the guy could become the SQL Server evangelist in the organization because now THAT'S what he knows.
另一件事是，这可能与情况的技术方面无关，而与其他开发人员的不安全感有关。这就是我所知道的一切。如果我们改变它，我不会理解它，然后我将在哪里寻找帮助他人成长的方法——当他遇到问题时，找一些能帮助他开发好的技术解决方案的资源。建议你部门的每个人都接受一些新技术的培训。谁知道呢，一个好的SQL Server课程，他就能成为组织里的SQL Server布道者，因为现在他知道了。
Lastly, know when to cut your losses, so to speak. If you find that you're not able to do anything about the situation, don't add to the complaining. Move on to something that you can control and do it as well as you can. Maybe in the future you'll be in a position that you do have control or influence in the situation and can do something about it. If you find that you're in a company that's more dysfunctional than most, find a way to move on to a place where the environment is better.
最后，可以说，知道什么时候减少损失。如果你发现你对这种情况无能为力，不要再抱怨了。继续做一些你能控制的事情，并尽可能地做好。也许在未来，你将处于一个你可以控制或影响的位置，并且可以做些什么。如果你发现你所在的公司比大多数人都更不正常，那就找一种方法，去一个环境更好的地方。
#6
2
It is possible, and actually fairly easy, to convert an Access database to having the tables/views in SQL Server while still using the Access app as a front-end.
在使用Access app作为前端的同时，将Access数据库转换为SQL Server中的表/视图是可能的，而且实际上相当容易。
From there, your Access-obsessed developer can still have fun with all that VBA code. Meanwhile, on the back-end, you add indexes and such to speed everything up. Maybe someday you get lucky, and he asks about stored procedures. Then, the app is just a front-end, and who cares what it's written in? Your data is safe in SQL Server.
从这里开始，痴迷于访问的开发人员仍然可以享受所有VBA代码。同时，在后端，添加索引等以加快一切。也许有一天你走运了，他问你存储过程。那么，这个应用程序只是一个前端，谁在乎它写的是什么呢?您的数据在SQL Server中是安全的。
It is possible for you to do this yourself, but just leave the production app ALOOOOOOOOOOOONE. Take a copy, and convert that copy. Then, host it for a couple of users to TEST drive .. make your version of the Access app show "TEST APP" in big red letters. If your developer asks what you're doing, you can say the truth -- you are testing to see if converting only the tables/views might be of some help to the overall app.
你可以自己做这个，但是只需要离开生产应用程序。拿一份拷贝，然后转换它。然后，将它托管给几个用户来测试驱动器。让你的访问应用程序的版本用红色大字显示“测试应用”。如果开发人员问你在做什么，你可以说实话——你在测试，看仅仅转换表/视图是否对整个应用程序有所帮助。
This way, you get the best of both worlds, keep your developer happy, make the users happier (hopefully), and if you play it right, your bosses will know that you handled a knotty personnel issue with your technological prowess and your maturity.
通过这种方式，您可以充分利用这两个方面，让您的开发人员感到高兴，让用户感到高兴(希望如此)，如果您操作得当，您的老板将知道您处理了一个棘手的人事问题，您的技术能力和您的成熟度。
#7
1
I once had similar problems with someone I would not hesistate to call a complete idiot.
我曾经和一个我不愿称其为完全白痴的人有过类似的问题。
It was not possible to convince them of the issues with access. In the end it was easier to force the issue than do it "nicely", cruel to be kind.
不可能使他们相信有关访问的问题。最后，解决这个问题比“好”、“仁慈”更容易。
#8
1
If they resist then you can always go above their head. Management must be aware of crashes and stability related issues. Present a plan to them to improve stability and they are likely to at least listen. They will probably then want a meeting with all developers to discuss so go into it armed with plenty of ammo.
如果他们拒绝了，你就可以超越他们的头。管理人员必须了解崩溃和稳定性相关的问题。向他们提出一个改善稳定性的计划，他们可能至少会听取他们的意见。他们可能会希望与所有开发人员开会讨论，所以带着足够的弹药进入。
#9
1
More than "How to convince them", let's talk about "How to do it without anybody noticing"!
除了“如何说服他们”，让我们来谈谈“如何在没有人注意的情况下做到这一点”!
First of all I advice you not to mix together the code optimisation issue and the SQL server one. Do not give users a chance to complain about SQL while bugs are related to something else.
首先，我建议您不要将代码优化问题和SQL server问题混为一谈。不要给用户一个机会去抱怨SQL，而bug与其他事情有关。
If your code is really unbearable, rewrite the app before switching to SQL, keeping in mind the following points to make the final transition to SQL Server completely transparent for final users.
如果您的代码实在难以忍受，那么在切换到SQL之前重写应用程序，记住以下几点，以便最终向SQL Server的转换对最终用户完全透明。
This is what we did 18 months ago, and I am sure we still have users thinking our database is Access:
这是我们18个月前所做的，我确信我们的用户仍然认为我们的数据库是Access:
- Export current access database to SQL through available Wizard in access for testing purposes (many problems might occur, and you could need another tool such as the one proposed here).
- 通过可用的向导将当前的访问数据库导出到SQL以供测试使用(可能会出现许多问题，您可能需要另一个工具，如本文中建议的工具)。
- Create a unique connection object at the application level, so that you can freely switch from Access to SQL at any time (at development level, you can even add an input box at startup to ask which connection to use). We chose an ADODB connection object, but it will also work with ODBC connection.
- 在应用程序级别创建一个唯一的连接对象，以便您可以在任何时候*地从访问切换到SQL(在开发级别，您甚至可以在启动时添加一个输入框来询问使用哪个连接)。我们选择了ADODB连接对象，但它也可以使用ODBC连接。
- In case you use SQL syntax to update tables, make sure that all SELECTs, INSERTs, UPDATEs and DELETEs make use of this connection. In case you use recordset, make sure that all of them use this connection at opening time.
- 如果您使用SQL语法更新表，请确保所有的选择、插入、更新和删除都使用此连接。如果您使用记录集，请确保所有的记录集都在打开时使用此连接。
- When needed, update all connexion specific code by adding a "SELECT CASE"
type_Of_TheConnexionoptions - 需要时，通过添加“选择案例”type_Of_TheConnexion选项更新所有connexion特定代码
- Switch to SQL connection ..and debug till you're done!
- 切换到SQL连接。调试，直到你完成!
The problems you will find are mainly linked to SQL syntax, where MSSQL uses ' instead of " and # as separators. Date format is also an issue, where standard SQL format is 'YYYYMMDD' while MS-Access format depends on computer locals (beware of conversions from date to string!) and is stored as "YYYY-MM-DD" (if I remember ...). Boolean in SQL are 0 and 1, while they are True/False or 0/-1 in Access ...
您将发现的问题主要与SQL语法相关，其中MSSQL使用“而不是”和#作为分隔符。日期格式也是一个问题，标准的SQL格式是“yyyyymmdd”，而MS-Access格式依赖于计算机局部变量(注意从日期到字符串的转换)，并存储为“yyyyyyy - mm - dd”(如果我记得…)。SQL中的布尔值为0和1，而访问中它们是True/False或0/-1。
Test, update code, and when you are ok, make a new data transfer, lock your app on the SQL connection, and distribute a new runtime.
测试、更新代码，当您没问题时，进行新的数据传输，在SQL连接上锁定应用程序，并分发新的运行时。
#10
1
It depends on the type of application and data load of your database but Access is quite efficient, even over the network.
Depending on the amount of data your users deal with you could easily scale up to a 100 users on a network just using a from and back-end Access database.
它取决于应用程序的类型和数据库的数据负载，但是访问是非常有效的，即使是通过网络。根据您的用户处理的数据量，只需使用from和后端访问数据库，就可以轻松地扩展到网络上的100个用户。
Looks like in your case a rewrite may be in order. If your application is data-centric if doesn't make much sense to develop it in VB6: the tools given by Access are much better than anything you'd be able to make, especially when considering Access 2007.
在您的例子中，重写可能是正确的。如果您的应用程序是以数据为中心的，那么在VB6中开发它就没有多大意义了:Access提供的工具要比您能够提供的任何工具都好得多，特别是在考虑Access 2007时。
Upsizing to SQL Server is only really required if you're getting into issues of:
只有在遇到以下问题时才真正需要对SQL Server进行升级:
-
Security:
you need to make sure that only the rights users can access data. You can do your own security in Access, but it's never going to be as strong as SQL Server. - 安全性:您需要确保只有权限用户才能访问数据。您可以在访问中实现自己的安全性，但它永远不会像SQL Server那样强大。
-
Scalability:
you're dealing with lots of data and complex queries or a lot of users and it would be better to have dedicated hardware to handle the load for the clients. The issue with this though is that while removing the pressure from the less-capable clients machines, you're adding a lot more to the server. - 可伸缩性:您正在处理大量的数据和复杂的查询或大量的用户，最好有专门的硬件来处理客户端的负载。但是，问题是，尽管从性能较差的客户端机器上消除了压力，但您向服务器添加的内容要多得多。
-
Integrity:
With the back-end database being just a file that needs R/W access for all connected clients, there's always the possibility that someone is going to do something bad or that a client may crash and leave the database corrupted. - 完整性:后端数据库只是一个文件，需要对所有连接的客户端进行R/W访问，因此总有可能有人做了坏事，或者客户端可能崩溃并导致数据库损坏。
If your number of users is average (I'd say 30), then there's probably no real need to upscale:
如果你的用户数量是平均的(我认为是30人)，那么你可能没有真正的需要去升级:
- Use MS Access 2007 to develop your application, then just use the MS Access 2007 Runtime (it's free!) on all client machines to get a more modern user interface (uses the Ribbon and has lots of UI enhancements over previous versions).
You can't be the cheapness of that solution : you only need full retail version of MS Access and all the rest is free, regardess of the number of users! - 使用MS Access 2007来开发应用程序，然后在所有客户端机器上使用MS Access 2007运行时(它是免费的!)来获得更现代的用户界面(使用Ribbon，与以前的版本相比有很多UI增强)。你不可能便宜的解决方案:你只需要完整的零售版本的MS Access，其余的都是免费的，不管用户的数量!
- Don't think that moving to SQL Server is going to improve performance of your queries: MS Access often does a better job of optimizing the queries for you (it knows what needs to be displayed and does lots of caching and optimization).
- 不要认为迁移到SQL Server将提高查询的性能:MS Access在优化查询方面通常做得更好(它知道需要显示什么，并进行大量缓存和优化)。
- Make sure you only edit small amounts of data at any one time (don't use dynaset queries just to display vast amounts of data in a datasheet; use a snapshot instead and open a detail form that only contains the data to edit when necessary.
- 确保每次只编辑少量数据(不要使用dynaset查询，只需要在数据表中显示大量数据;使用快照，打开一个细节表单，其中只包含需要编辑的数据。
- Cache complex queries locally.
Built some caching mechanism that leaves a copy of the results of a complex query on the local machine. The gain in performance is pretty amazing and if the query doens't change much (for instance a log of stock operations) you can just persist the complex/big query locally and append new records as necessary. - 在本地缓存复杂查询。构建了一些缓存机制，在本地机器上留下复杂查询结果的副本。性能的提高非常惊人，如果查询变化不大(例如股票操作日志)，您可以在本地持久化复杂/大型查询，并根据需要附加新记录。
There is so much more to say.
还有很多话要说。
Bottom line is: you may be looking at a rewrite, but don't dismiss Access as the solution because your current application was poorly written.
底线是:您可能正在查看重写，但是不要因为当前应用程序编写得很糟糕而将访问排除为解决方案。
#11
0
Try bechmarking and showing the stats to him
试试做标记，给他看统计数据
#12
0
Here is an in depth list of reasons why you might consider moving straight from Microsoft:
以下是你可能会考虑直接从微软跳槽的原因:
http://msdn.microsoft.com/en-us/library/aa902657(SQL.80).aspx
http://msdn.microsoft.com/en-us/library/aa902657(SQL.80). aspx
#13
0
Making people change can sometimes be a real pain in the butt.
让人们改变有时会让人痛苦。
I would have to say the main argument would have stability and speed, but of course like you have said they already know this a still won't move.
Another thing to try would be to show them the power of LINQ to SQL and how much cleaner it would make your application. Like Daniel Silveira said you could try and throw a couple of stats there way and see if they are convinced.
我不得不说主要的论点会有稳定性和速度，但是当然像你说的他们已经知道a仍然不会移动。另一件需要尝试的事情是向他们展示LINQ对SQL的强大功能，以及它将使您的应用程序变得多么干净。就像丹尼尔·西尔维拉说的那样，你可以试着投一些数据，看看他们是否信服。
We have a app build using MS access as a back end and I can't wait till we get our new SQL server so I can move everything to that.
我们有一个应用程序构建，使用MS access作为后端，我不能等到我们得到新的SQL server，这样我就可以移动所有的东西。
#14
0
You could show him the perf results comparing the two, but if he's really set in his ways and refuses to change, there isn't much you can do except force him somehow.
你可以给他看比较这两个结果的结果，但是如果他真的固守自己的方式并且拒绝改变，你除了以某种方式强迫他之外没有什么可以做的。
If you're his boss then just force him to change it to use SQL. If not, then convince your boss to force the change by showing him the perf results and explain it'll fix the issues you're having.
如果你是他的老板，那就强迫他修改为使用SQL。如果没有，那就向你的老板展示你的绩效考核结果，并向他解释这能解决你的问题，以此来说服他做出改变。
#15
0
Errr, leave the team? You seem to be working with the totally wrong set of people. Now, if the team IS your company, then you are working with the wrong company.
哦,离开团队了吗?你似乎在和完全错误的人打交道。现在，如果团队是你的公司，那么你是在错误的公司工作。
Of course once you leave the company, you could tell your clients that you could solve the network problems on their own and make them leave the company as well. Then give them an improved system that works on SQL Server Express.
当然，一旦你离开公司，你可以告诉你的客户你可以自己解决网络问题，让他们也离开公司。然后为他们提供一个在SQL Server Express上工作的改进系统。