Future of Access (5 Viewers)

[BlueSpruce]

A guide? Not a document as such. That's actually beyond the scope of the charter for Microsoft templates in general.

We went to some trouble to provide a consistent Relationship Diagram for the Developer version because otherwise it's generated in the muddled state typical of newly created databases.

Over the years, I've seen dozens of articles that attempt to explain database Normalization, Normal Forms, table design, etc. A typical web search should turn up a boatload of them. You can even find very good YouTube videos on the subject.

I doubt there would be much incremental value to trying to limit one to Access applications in particular, though. All relational databases are built on the same principles, regardless of the database itself. A Primary Key is a Primary Key, in other words. So building a normalized Access database application differs only in the degree of complexity starters will implement.

My own original attempt at explaining it was in my first book, back in 2004. I did a marginal job of it, unfortunately for my pride, but I felt good about it at the time.

It doesn't matter that much, though, in a practical sense, with regard to Excel users. They don't know what they don't know when the decide to tackle Access. So, unless they are brilliant, or just unusually lucky, they blunder on until they realize what they've created doesn't work. At that point, many of them begin their search for help, eventually stumbling into someone who shakes a finger in their face and shouts "Normalize" at them.

The analogy of the cardboard box in your Data Modeling 101 (2004) book chapter is great for beginners, but I think now most people who want to learn how to develop an Acess app, by example, are going to reference your NW2 template. Therefore:

I feel it would be worthwhile to provide a new guide that shows Excel users how to properly design and build a normalised Access application. The guide could show examples of NW2 data in flat Excel sheets and how that data should be organized in Access tables, and explanations in layman terms of the rules for 3rd Normal Form, which is sufficient enough for properly building Access apps. This topic really doesn't have to be that long to guide users in the right direction.

 

[AHeyne]

It works for me and @isladogs.
Try this link:

https://portal.ct.gov/-/media/ott/ott-office-365-online-training/6office365freebookaccess365.pdf

Or search for "CT.gov Access 365 pdf"

Notice that the summary of that weblink is enough to deter users from exploring Access.

View attachment 121546

Ok, the problem seems to belong to my location:

The Amazon CloudFront distribution is configured to block access from your country.

But it's no problem. It's not that important.

 

[GPGeorge]

The analogy of the cardboard box in your Data Modeling 101 (2004) book chapter is great for beginners, but I think now most people who want to learn how to develop an Acess app, by example, are going to reference your NW2 template. Therefore:

I feel it would be worthwhile to provide a new guide that shows Excel users how to properly design and build a normalised Access application. The guide could show examples of NW2 data in flat Excel sheets and how that data should be organized in Access tables, and explanations in layman terms of the rules for 3rd Normal Form, which is sufficient enough for properly building Access apps. This topic really doesn't have to be that long to guide users in the right direction.

As I said, there have been many such attempts to provide guidelines for designing and building normalized relational databases, some brilliant, some less so. I bet a search right here at AWF would turn up more than one.

The problem, as I see it, isn't a lack of written guides. The problem is that most people just starting out have no idea they even need such a guide before they begin. They jump in, importing a spreadsheet and hacking away. Only when they fail to achieve something usable do they start looking around for help. If they're lucky they find a discussion on Relational Database design and/or Database Normalization and take it seriously. We've all seen those cases, however, when they refuse to give up what they've already done just because they're informed there is a better way.

I remember saying many years ago, and only partly in jest, that in place of a license, users should have to pass a short test on Database Normalization before being permitted to install Access on their computers.

All of that said, if you have time, perhaps you'd be able take up the task of writing a new guide for Access relational design. It certainly couldn't hurt.

 

[BlueSpruce]

As I said, there have been many such attempts to provide guidelines for designing and building normalized relational databases, some brilliant, some less so. I bet a search right here at AWF would turn up more than one.

The problem, as I see it, isn't a lack of written guides. The problem is that most people just starting out have no idea they even need such a guide before they begin. They jump in, importing a spreadsheet and hacking away. Only when they fail to achieve something usable do they start looking around for help. If they're lucky they find a discussion on Relational Database design and/or Database Normalization and take it seriously. We've all seen those cases, however, when they refuse to give up what they've already done just because they're informed there is a better way.

I remember saying many years ago, and only partly in jest, that in place of a license, users should have to pass a short test on Database Normalization before being permitted to install Access on their computers.

All of that said, if you have time, perhaps you'd be able take up the task of writing a new guide for Access relational design. It certainly couldn't hurt.

So therefore, it should be built into Access itself to ensure newbies read and follow the rules. That can be disabled later on by changing the help level, just like when Word 2000 use to have help levels 1,2, and 3.

After all, wasn't Access originally built as a user-friendly database tool?

Perhaps you could suggest this idea to the MS Access Team Manager?

If MS where to build in that feature, there would be less Access users needing their apps to be rescued by experienced developers, a double-edged sword. Which scenario do you prefer?

 

[The_Doc_Man]

Well I learned something skimming the first part of that PDF where I read that …A dynaset is not to be confused with a dinosaur.

No, we who USE Access are closer to being the dinosaurs. Or at least that is how we are treated sometimes.

 

[BlueSpruce]

No, we who USE Access are closer to being the dinosaurs. Or at least that is how we are treated sometimes.

I kno several developers, like me, who have been using Access to quickly build mockup apps, versus building DotNet prototypes with Visual Studio. I am currently doing this with the Healthcare Documents Management app for a presentation I am doing next week. So Access is not extinct, like the dinosaurs. It's alive and kicking, just like COBOL is, in enterprise settings like State and Federal Government.

 

[CompSMART]

No, we who USE Access are closer to being the dinosaurs. Or at least that is how we are treated sometimes.

I'm going to place myself in the dinosaur category. When I see an Access database developed without any adoption of the Leszynski/Reddick naming convention (or at least some flavor thereof), I start uncontrollably shaking my head no.

 

[The_Doc_Man]

I'm going to place myself in the dinosaur category. When I see an Access database developed without any adoption of the Leszynski/Reddick naming convention (or at least some flavor thereof), I start uncontrollably shaking my head no.

While I understand that emotion, I remember a discussion on this forum some years ago about naming conventions. After a long bit of back-and-forth discussions, we reached two basic conclusions.

First, many new Access users had no naming conventions. We decided if you had one at all, even if it wasn't very sophisticated, you were already ahead of the game.

Second, if you actually HAD a convention, it was great if you just remembered to use it all of the time.

 

[BlueSpruce]

While I understand that emotion, I remember a discussion on this forum some years ago about naming conventions. After a long bit of back-and-forth discussions, we reached two basic conclusions.

First, many new Access users had no naming conventions. We decided if you had one at all, even if it wasn't very sophisticated, you were already ahead of the game.

Second, if you actually HAD a convention, it was great if you just remembered to use it all of the time.

The real big winner is when newbies use space characters when naming objects.

 

[GPGeorge]

So therefore, it should be built into Access itself to ensure newbies read and follow the rules. That can be disabled later on by changing the help level, just like when Word 2000 use to have help levels 1,2, and 3.

After all, wasn't Access originally built as a user-friendly database tool?

Perhaps you could suggest this idea to the MS Access Team Manager?

If MS where to build in that feature, there would be less Access users needing their apps to be rescued by experienced developers, a double-edged sword. Which scenario do you prefer?

I don't have direct contact with the MS Access team any longer.

With all of the other priorities already on their plate, I don't think I'd try to insert this particular initiative into their plans anyway.

I'm also skeptical that adding such a guide would make all that much difference anyway. Perhaps, though, this is an idea for an Add-in that someone could produce and distribute, or even sell.

 

[CJ_London]

when creating a field name, if you use a reserved word Access usually gives you a heads up that it is not a good idea - could apply the same principle to spaces - doesn't stop you using them but gives fair warning.

I remember many years ago someone argued strongly that spaces in field names was a good idea because when you create a form or report, you didn't need to modify the labels to include spaces - so saved time. And thought that populating the field caption property was too much effort. Suspect they didn't use VBA

 

[Imb]

I remember many years ago someone argued strongly that spaces in field names was a good idea because when you create a form or report, you didn't need to modify the labels to include spaces - so saved time. And thought that populating the field caption property was too much effort. Suspect they didn't use VBA

That is why I use underscores for objectnames: for display purposes replace the underscore by a space.

 

[JeffBoyceIF]

Hello Everyone,

I had recently joined the UtterAccess forum, but unfortunately that site was permanently shutdown without any advance warning. I am a team member of four Access developers and we are concerned about the stability and future of Access.

Are you saying that the shutdown of UtterAccess is somehow related to the "stability & future of Access"? Or perhaps you are privy to information about Access' future?

 

[The_Doc_Man]

Hello, @JeffBoyceIF - are you aware of the reason WHY UA shut down? We have threads accessible through our "Similar Threads" feature.

As to the future of Access, the first time I heard it was going away was about 20 years ago, and every so often something comes up again on the same subject. We don't have X-ray vision to see inside the meeting rooms in Oregon, so can't read their memos. HOWEVER, some of us on this forum - GPGeorge and Isladogs to name two out of MANY - monitor the announced plans for the MS Access team and there seems to be a future plan for further upgrades and fixes.

Can anyone see MS's future? Nope, it's a black box as far as most of us are concerned. All we can do for now is carry on and see if at some point there is a more readable disturbance in the force.

 

[CompSMART]

the first time I heard it was going away was about 20 years ago

 

[BlueSpruce]

I think most of those issues are in the past. Chat can take pretty much any spread sheet and spit out the properly normalized database. For fun I took NW and made a large query with all the tables and many of the fields. Asked chat to make a properly normalized database from the flat excel file.

1. Categories
CategoryID (PK)
CategoryName
Description

2. Customers
CustomerID (PK)
CustomerCompany
ContactName
ContactTitle
CustomerAddress

3. Employees
EmployeeID (PK)
EmployeeFirstName
EmployeeLastName

4. Suppliers
SupplierID (PK)
SupplierCompany

5. Products
ProductID (PK)
ProductName
SupplierID (FK)
QuantityPerUnit
UnitPrice
UnitsInStock
UnitsOnOrder
ReorderLevel
Discontinued

6. Shipping Companies
ShipCompanyID (PK)
ShipCompanyName
ShipCompanyPhone

7. Orders
OrderID (PK)
OrderDate
RequiredDate
ShippedDate
CustomerID (FK)
EmployeeID (FK)
ShipCompanyID (FK)

8. Order Details
OrderID (FK)
ProductID (FK)
UnitPrice

Then asks if you want the code to generate the tables in sql, export to csv, or get an ER diagram.

True, but if your average newbie doesn't learn what normalisation is, he won't know what to ask for and continue building out his Access app with an Excel mentality.

If people rely on AI to do everything for them, we're going to breed a new generation of dumb lazy people that won't learn how to master any skills on their own.

 

[BlueSpruce]

Are you saying that the shutdown of UtterAccess is somehow related to the "stability & future of Access"? Or perhaps you are privy to information about Access' future?

Hi Jeff, the abrupt UA shutdown happened because it's owner was arrested and indicted on Fededral charges of trafficking child pornography.

See this thread:

https://www.access-programmers.co.u...-about-utteraccess-owner.334495/#post-1972018