Access: The DB that will not die

[NauticalGent]

My wife, of all people, sent me this article. Have a read, it is good stuff and absolutely nails it...

https://medium.com/young-coder/micr...-database-software-that-wont-die-5b09e389c166

 

[isladogs]

By chance I found the same article today in a post at MSDN forums
https://social.msdn.microsoft.com/Forums/en-US/00a99464-8f0e-40c8-9638-95777371ef9d/zombie-software-eh?forum=accessdev

Whilst I agree with much of the article, one of the responses at MSDN rightly points out that the failed attempts to port Access to the Web were done in an attempt to increase its user base rather than kill it off as the article suggests

 

[jdraw]

I agree that the intended move to include web applications in MS Access was to expand the user base as Colin noted. Too often it seemed that Access had been forgotten when newer versions of Office products were being identified and heavily marketed. Many asked -What about Access? with very little positive info from M$oft. Many user groups and forums kept asking, and even wrote articles on the usability and growing installed base to support the longevity of the product. It seemed M$oft treated Access like the red headed stepchild. The most positive Access news from M$oft came about a year ago from Michal Bar, after ~15 years of growing uncertainty. There has been an effort within to bring Access documentation current and consistent.

The author seems focused on the DB part and not the RAD/FE to anything aspect of Access.

I have experienced how querying/extracting and reporting from Oracle databases was supported and simplified by using MS Access (ODBC). Also developing related and managed subsystems in Access was quite cost effective. My thinking is that Access is probably used within those organizations identifying Oracle, MySQL, SQL Server, PostgresSQL... more than suggested in the article.
Here's to the next 10 years!!!

 

[gemma-the-husky]

The thing is, the same people who dismiss robust carefully designed access databases, never see the parallel with allowing a proliferation of poorly designed mission critical excel spreadsheets within their businesses.

"do you want to open the spreadsheet read only?"


All they (ie MS) need to do with access is
a) improve the security model. Let Access have "access" to the backend database without the user needing full permissions on the folder.
b) find a way to run a multi user database over a WAN. eg Back end access database in the cloud.

Personally, I don't think access is about the "power-user" so much. That power user is likely to apply the same tools he uses for a spreadsheet, and then wonder why things are hard.

I think it's more about a competent, professional developer applying a carefully thought out design to the end database, and thereby creating a robust and friendly experience for the user.

A great deal of this is actually to restrict the user (including the designer) from using every tool that access provides. That's why you need a lot of code, defensive code, inside databases.

 

[sonic8]

All they (ie MS) need to do with access is
a) improve the security model. Let Access have "access" to the backend database without the user needing full permissions on the folder.
b) find a way to run a multi user database over a WAN. eg Back end access database in the cloud.

They did that already!

The special Access backend type you need to use for that is called SQL Server!


No, seriously, Access´ strength (and gravest weakness) is that is just file based. So, it total depends on file system level access to any database file. Obviously file system permissions and the risk of corrupting files apply then.


Once you decouple an Access frontend from file system based access to the backend you need an active component on the server to manage access to the data. Such an component is a database server. So, there we are. Install SQL Server and you get what you asked for right away.

 

[gemma-the-husky]

Yes, but with SQL Server you need an additional skillset that you don't need with Jet/Ace,

 

[sonic8]

Yes, but with SQL Server you need an additional skillset that you don't need with Jet/Ace,

If Access had the additional features you wished for, you would also need an additional skillset to handle them properly.

 

[NauticalGent]

Got this in an email today. It is a response from Juan Soto:

https://accessexperts.com/blog/2019/11/09/the-office-product-that-refuses-to-die/

 

[isladogs]

Thanks for the link. A good response.

The original article has certainly got a lot of attention here and elsewhere including UA and MSDN forums. Perhaps that was its main purpose.

Although the author did make some valid points, the consensus from a large number of respondents at seems to be that the points made by him are highly selective and that he is ignoring or misrepresenting anything that doesn't fit his conclusions.

 

[gemma-the-husky]

@Pat

I am sure the reason Jet/Ace back ends get conflated with Access is simply because MS ship Access as an integrated solution. Users (eventually) realise they can split a database into an Access front end and an "Access" back end, and therefore wonder about putting that Access back end into the cloud, to improve connection possibilities.

Coincidentally there is another thread current about using one drive/dropbox to store an "Access" back end.

As you mention, Windows comes with Ace/Jet support, and you can find .mdbs and probably .accdbs somewhere on your hard disk, without installing Access at all.