Future of Access

[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 the 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

 

[DHookom]

Hi Jeff, the abrupt UA shutdown happened because the 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

I wasn't aware of this. I had met him at an MVP Summit.

 

[Isaac]

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.

 

[isladogs]

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

 

[Isaac]

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