Future of Access

  • Thread starter Thread starter Deleted Bruce 182381
  • Start date Start date
Since I don't use ADO, I'm not sure - but if it is at all like DAO, it will have the same issues as opening with DAO. You send the status as a file operation, not a DB operation. Where is .FuncSendStatus defined? This looks like air code since your WITH variable, cn, isn't defined.

I remain skeptical. I return to Pat's and my suggestion that at some point it is less convoluted to just instruct folks how to shut it down and start with a freshly loaded copy. And if that fails during its restart, the network wasn't ready yet.
 
In the final analysis, all I can suggest is that if you want to try this, go ahead. The best that can happen is that you have found your way through the maze and win the prize. The worst that can happen is that it doesn't work. I've given you the background to understand the most probable network behavior of this process. I think you are striving for a really complex solution when a simpler solution is available. I remain skeptical but I can (and DO) wish you good luck in the attempt, if you choose to make it.
 
@GPGeorge, Does NW2 provide a guide that thoroughly explains how to properly design and build a normalised Access application?
Most newbies who explore Access are Excel users, and by habit, they will build denormalized Excel_like Access apps, unless we thoroughly educate them about normalized database design. This is sorely needed, as I have not seen any adequate content about the subject matter.
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.

1758210466425.png


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.
 
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
 
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.
 
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?
 
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.
 
We are also concerned that for security purposes, Microsoft will restrict VBA from being able to manipulate the Windows Filesystem, e.g. FSO, Shell Commands, Automation, etc. Web Applications are stateless with no binding. That was main reason for Classic Outlook being replaced with webmail Outlook. VBA cannot automate webmail.
I think THAT is a valid concern, and sounds exactly like the type of thing Microsoft would do. Either restrict vba from doing it or restrict apps from running vba. They already aggressively warn users as if it is suspiciously bad content in all cases except that you bypass it. They don't do that for other programs, once you install it, you're good to go.
 
I don’t agree about this being a valid concern.

Although I don’t agree with the decision to remove VBA support from New Outlook, it was a somewhat unique case.

Over the years MS had created multiple versions of Outlook, for PC and Mac, both desktop based and web based. This meant there were multiple code bases to maintain which was expensive in terms of developer time. The Office Watch blog has written about this extensively.

Rationalising all of those into a single code base made sense, even though the end result is far from satisfactory as far as developers in Access/Excel etc are concerned.

Access is different. It is desktop PC only. One code base only. One of its main selling points is its ability to work with a very wide variety of file formats using automation. Removing that functionality would completely change its purpose in a negative way and have no financial benefit for MS. Therefore it won’t happen
 
Sure hope you're right :)
Then you also have to consider AV software that some aggressive IT departments maintain. I once worked at a place where when I ran code that automatically created a BAT file - the instant the textstream was Closed, the .bat file was zapped - it disappeared. All it would take is some AV software to prohibit vba and we'd be toast.

Another thing to think about is AI. AI why, you say? Because I believe that the future looks a lot more like people being expected to achieve a high level of productivity by way of utilizing AI as often as possible/reasonable. And from my experience so far, AI is pretty terrible at VBA, whereas it has devoted tons of resources to perfecting its responses on, for example, Python (to the extent that it actually creates its own python scripts behind the scenes to accomplish things!). So what I'm saying is if AI leaves Access in the dust, a lot of people might leave Access in the dust, because the world is slowly going in the direction where "what's within the scope of good responses from LLM's" will be a deciding factor in what to use.
Of course, theoretically, there is no arbitrary limitation on AI and AI can and should provide help in VBA. But my point is, similar to Microsoft's position on VBA, it's definitely NOT a favored language, in fact it's a disfavored language and that influence is not going to do us any good as the general direction of things
 

Users who are viewing this thread

Back
Top Bottom