Thanks Richard!

Hi Woody,

Glad this info is helpful.

To deploy a runtime application, you definitely need to have a solid error handling system in place so the user doesn't experience a nasty crash without gracefully exiting, and you have the code to document what happened so you can fix it. This is the same issue if you deploy an MDE or ACCDE program because the Cancel/Debug dialog isn't going to work.

At that point, the runtime version is simply a licensing issue. Some features like spell checking aren't part of the Runtime program because that's part of Office. Essentially, it's Access's way of competing against other programs that let you create an EXE or DLL and distribute it without having to pay for each user.

Here's some feedback related to a question about the Microsoft Access 2GB database limit indicating it's not scalable and therefore not appropriate for use:

MS Access fits between what people do with Excel and what enterprises do to create large, scalable, mission critical applications.

Access scalability should be a secondary consideration of whether Access is appropriate or not. I would postulate that 99+% of Access databases (and desktop databases) never run into the 2 GB limit, so scalability is more of the exception than the rule. It's really hard for people to type that much information even after several years. Similarly, most Excel spreadsheets never get that big either. To drop a technology in fear that someone may create something wildly successful is inappropriate.

Even if scalability were an issue and the 2 GB limit encountered, we agree that SQL Server is an appropriate storage platform for the data. In that case, Access is perfectly fine as a front-end to that. Should end-users rely on others to create reports and view data that they could do on their own with Access? Seems like a waste of professional developer time for those situations.

I agree that people create bad database applications. But I would say that is not technology specific. There are lots of terrible applications written with SQL Server, .NET, Java, Oracle, SAP, Excel, etc. The more important question is whether the technology and user were able to solve their immediate problem versus their alternatives at the time, and whether the organization can leverage what they built if it's successful. Even if it's decided to throw away what's already built, the fact that something exists is very helpful.

My experience is that most organizations don't have the time or resources to build every database application that their line of businesses need. It's wrong to look at the applications that need to be migrated to a better developer or platform and say that it would have been better or cheaper to build it "right" originally:

• Originally, the design would not have been known the way it is today. It was the actual evolutionary process for the solution to become what it is today. Interrogating the original author for his vision to get to today's functionality would be impossible even if you were allowed to use waterboarding.
• The database evolution was partly controllable but mostly not. That is, the changes occured due to external forces unrelated to technology (e.g. the economy, competitors, new products, management decisions, etc.)
• Only a small percentage (under 5%) of workgroup level databases ever need centralized IT involvement, and that's after several years
• If organization don't allow information workers to create simple databases applications on their own, the IT department needs to create all of them for them when less than 5% should involve them. The costs would be astronomical and turn around times very long. It's basically giving opportunities to competitors.

So yes, giving people matches may create uncontrolled fires, but that's why we have fire alarms and firemen. We don't tell people they can't use fire and force them to eat everything raw or pay a huge amount if they want something cooked. There is a middle ground. Organizations that manage this well gain a huge competitive advantage, and their IT departments really focus on what's strategic.