Access On New Computer

[NauticalGent]

Access feature comparison chart.

 

[The_Doc_Man]

I absolutely understand @amorosik's desire for that older version. If it is going to run on an older computer, then compatibility won't be an issue. However, there are considerations as time goes on. Even if you intend to leave things in their older state, time IS marching on around you. Two scenarios come to mind.

One is that if this is an old version of Access on a newer computer, automated Microsoft patching has become insistent these days. You can hold off patching for a while, but Win10 only lets you block patching temporarily. At some point it will say (in effect) "I'm going to patch you now. Shutting down...." and you can't stop it unless you are a registry hack wizard. At which point (and based on past behavior including posts in this forum) some patch will kill some element of the older Office library and you are done.

A second scenario is that you are running this archaic software and you have to expose it to the Internet in some way. So you have an anti-virus package. Because you are maintaining backwards compatibility for Access, you have to continue to run an older version of Windows. Just because the hackers are modernizing, they are still looking for "low-hanging fruit" to pluck. And older versions of Windows have SO many known vulnerabilities. Eventually your A/V package that handles that clunking old version of Windows is no longer updating because the A/V vendor ALSO has to have a limit on how much support to offer based on dollar value offered by supporting that older O/S. It comes back down to "Does support of DOS 6.2/Win 3.1 by our package return enough to cover the cost of that support?"

Some years ago, long before my Navy job, I worked for a company that made industrial control systems that included building energy management for multi-acre factories with HVAC control encompassing dozens of "zones" to be kept warm or cold on particular schedules. We had a customer in the Michigan area who was getting a system just as my employer got bought out by typical corporate issues, mostly cash flow and an incredibly optimistic AND STUPID vice-president of Marketing.

The new company president was asked about a support issue and I overheard him ask "How much more money do they owe us on our current contract?" When he got the answer, about $12K, his response was "Screw them, write off their last payment and let them purchase support at our new rates." (This was maybe 40 years ago.) He was ignoring the warranty because a loophole in his state laws allowed him to drop warranties that were part of a buyout. Now I'm seeing the same issue in Microsoft, a hard-nosed and callous disregard for customers when the dollar value is not there and they don't see it as impairing their public image.

The CrowdStrike issue WILL get fixed because public image is going to radically affect future sales. Trust me, the dollar value of "image" has been well and thoroughly calculated. But as to support for Access 2003, which is 21-year-old software, the public image dollar value is nil. If CrowdStrike doesn't support their "Falcon" package, they might as well close their doors. But if Microsoft stops supporting Access 2003... wait a minute, they HAVE done so... and they are still open.

By the way, regarding 2003's User Level Security, that was the MDAC module... Microsoft Data Access Control. In about 2005, the SANS Corporation's "top 20 riskiest software" list had MDAC as #5. It was insanely easy to spoof. Let's be honest, Access is not the hardest package in the world to hack.

 

[DickyP]

Beauty is in the eye of the beholder.

Access feature comparison chart.

The the chart is great but it merely proves exactly my point -

- TO ME there are few advantages, and significant omissions in Access 2021 over 2003.

My post was always about my preferences, and usage.

 

[NauticalGent]

The the chart is great but it merely proves exactly my point -

I gave my thumbs up because seeing the "evolution" of Access intrigued me. If I had my "druthers", I would have MS rollback to 2010 and start from there with the strict injunction that they could not remove anything...

 

[Pat Hartman]

Secondly I miss menus - I know this ship has long since sailed but it doesn't alter the fact that they are more logical, more flexible, easier to create and maintain than ribbons, and you can put them where you want them. Not to mention the flawed logic that icons are easier to understand than words.

I've almost gotten used to the ribbon after 17 years but I still really miss the Access database container. It was far more functional than the Nav pain (sic). All it needed was a better search. Far fewer clicks to do anything.

I understand that the reason the MS team went with the Ribbon instead of the menus was because they were easier to manage. Well, maybe for them but not for us. The best menuing system is one that is data driven so instead of writing code, you just add rows to a table or rearrange them if you want to change the sorting and grouping. THAT would have been an improvement. Then we have the Icons. Icons are stylistic and they actually change from version to version which is NOT helpful. We recently had a thread about some icon change regarding the line control on a form. The icon went from something that resembled a line to a zigzag which didn't come close to representing a one dimensional object. I also complain to companies that offer video content. Seeing a picture that represents a movie is useless. I'd rather have a faster search that provided a list where I could see a couple of key items like the name, date, and primary genre.

 

[DickyP]

I've almost gotten used to the ribbon after 17 years but I still really miss the Access database container. It was far more functional than the Nav pain (sic). All it needed was a better search. Far fewer clicks to do anything.re.

Purely apocryphal in that we are now 14+ years on but I was told as an aside by an MS employee at slough that the team given the task of converting the menu system to xml, refused to talk to the team responsible for the menus in office and just said huge chunks of functionality were pointless so didn't bother. The same person also said that the reason the picture manager was abandoned was because the only programmer left who maintained it retired, and nobody else understood the code. This is all third hand so take with a pinch or grain (select as preferred) of salt.

 

[Pat Hartman]

None of that surprises me at all. I was at the meeting in Redmond when the Access team unveiled the A2007 beta. We spent three days with the MS programmers going over the changes they had made and why. One of the children's "big ideas" about the conversion from the Database Window to the Navigation pain (sic) was that the team decided that the Nav pain should replace the Switchboard and therefore be used by the user to run the app. The problems with the concept are many.
1. The Access team developers don't actually develop applications using Access and apparently didn't propose this to the MVP group whose members do, prior to implementing it so we got no input. It was a fait accompli and the MS team wasn't changing it 8 months before release.
2. The MS team also did away with the existing security model so there was no way to keep certain things from the user.
3. The way the user works is not necessarily the way that you want to work. So, by making the "production" interface the same as the "development" interface, they made Access more Excel-like which wasn't a good thing.
4. At a practical level, it takes 6 clicks to do things that could be done with a single click in the Database Window such as simply changing the sort order. So, every day I work with access, 17 years after the fact, I still remember what they broke when most of you have never even seen the Database Window.

The biggest fight that week though was over the abomination data types. We didn't win that one either but at least since they are not part of the interface, we simply ignored the new data types. It isn't possible to ignore the Nav pain. For a while, I used my own version of the Database Window but that also has problems because it required me to add the form to every database I opened which is quite the pain when trying to help someone from the forum. Then as I made improvements, it was annoying to open a db to find the old version of the form and have to reload the newest version.

 

[Isaac]

I gave my thumbs up because seeing the "evolution" of Access intrigued me. If I had my "druthers", I would have MS rollback to 2010 and start from there with the strict injunction that they could not remove anything...

Yep, agree. 2007 or 2010 I would take indefinitely. The rest is just UI changes-for-the-sake-of-changes crap

 

[KitaYama]

I'm not surprised when someone new to Access or ribbon talks like this, but when experts here insist on preferring using traditional menus over ribbons, I'm simply shocked. No offence, but if anyone thinks the traditional menus were better and more useful than current ribbon, I say you don't know how to use a ribbon.
I've had this discussion with isladogs before. It's buried somewhere here, and I don't want to go through the same routine, just adding some points.

In a ribbon, you can add Checkboxes, Toggle buttons, Textboxes, Combo boxes, Galleries and Split buttons which I don't think menu system could have them.
And if you add a sub menu, you can have Toggle buttons and checkboxes in them too. (Again I don't think it was possible in a menu)

One of the most interesting aspects of controls on a ribbon, is that they can have a super tip, something that traditional menu system lacked. (at least with this quality). A super tip can be a help file or a complete explanation of how the control works. A super tip can be multi line, and styled with html.

However, some applications use custom add-ins or third-party tools to enhance the ribbon functionality. These add-ins can provide more advanced features, such as displaying images or even GIFs when hovering over controls. This involves programming with the Office Add-in framework, which allows developers to create custom UI elements and behaviors.
Check the following gif. A mouse over a control, shows a clip on how the control is supposed to be used.

I understand that the reason the MS team went with the Ribbon instead of the menus was because they were easier to manage. Well, maybe for them but not for us. The best menuing system is one that is data driven so instead of writing code, you just add rows to a table or rearrange them if you want to change the sorting and grouping.

That is the exact way a ribbon works.
Most of our databases have 4 user defined tables (tblRibbons, tblTabs, tblGroups & tblcontrols) that is joined to a users level table.
On each login, a function reads the preferences and privileges of users and reconstruct the ribbon's XML according to their preferred language. Their ribbon contains only the buttons they are allowed to use.
Adding new tabs, groups or controls is done only by adding a new record to one of the tables. We don't need to go through an xml file with more than a thousands lines, search for an specific control to edit, delete or add a new control.

When you login to one of our databases, the menu can be one of 8 possible languages. After login to FE, a function with less than 50 lines of code, reads the controls from a query with above tables joined, creates the necessary xml code that only contains the controls you are allowed to use, in your preferred language, and sets this XML as the application's ribbon.
What else do you need? You only add controls to the table, nothing else.

I think I've shared a sample database there and I don't repeat it here, just check how a dynamic ribbon works.

I can't remember how I used to add a menu to a database, so for anyone who remembers I have 2 questions: (genuine question)

• Were you able to have a multi language menu? For example when a French logs in to db, all the menu change to French, or to German for someone who is more comfortable with German than English. Was it possible?
• Could you hide some menus or sub menus for some users with less privileges?

 

[Isaac]

menus were better and more useful than ribbon

some of us are rabidly fast (in other words, extremely fast) keyboarders. the alt shortcuts were our lifeline.

regardless, i said i like 2007 and 2010. which have ribbon. I have only a tiny bit of ill-will against ribbon at this time

 

[Isaac]

Could you hide some menus or sub menus for some users with less privileges?

Sure, just use a tab control and make tab pages visible or invisible or change them back if no security, simple

 

[KitaYama]

Sure, just use a tab control and make tab pages visible or invisible or change them back if no security, simple

Tab control? Tab control belongs to forms, I think.
I had a feeling the discussion was about menu.
Did menu (at the top of the application) have tab controls?
(sorry for the stupid question. I can't remember.)

 

[KitaYama]

some of us are rabidly fast (in other words, extremely fast) keyboarders. the alt shortcuts were our lifeline.

Well, it's still available in ribbon.
You can add a Keytip property to a control.

<button id="customButton" label="My Button" keytip="B" />

Pressing Alt+B will fire its event.

 

[gemma-the-husky]

I gave my thumbs up because seeing the "evolution" of Access intrigued me. If I had my "druthers", I would have MS rollback to 2010 and start from there with the strict injunction that they could not remove anything...

I don't know about that. I just think A97 and then A2003 were very mature and you could whatever you wanted with them, pretty much.

Later versions added in new features such as formatted text boxes, form control anchoring, new ribbons instead of menus. I doubt there is any way that later versions can manipulate data, though, that couldn't be done in the A97/2003 versions.

However if you are forced to upgrade to W11, and maybe 64bit office you may be faced with a situation where you have to update the database for compatibility reasons. It may be automatically done by building in a later version. However you can't change A97 to A2023 without converting to A2003 first. You might have included code units that only work in 32bit office, so the developer has to solve the problem for their users.

There is so much important legacy software that companies use, that it's going to be a very expensive and difficult fix in many cases.

It's a bit like complaining that modern bluray players can't play VHS tapes, and what are you going to do about it, Panasonic?

 

[gemma-the-husky]

I'm not surprised when someone new to Access or ribbon talks like this, but when experts here insist on preferring using traditional menus over ribbons, I'm simply shocked. No offence, but if anyone thinks the traditional menus were better and more useful than current ribbon, I say you don't know how to use a ribbon.
I've had this discussion with isladogs before. It's buried somewhere here, and I don't want to go through the same routine, just adding some points.

In a ribbon, you can add Checkboxes, Toggle buttons, Textboxes, Combo boxes, Galleries and Split buttons which I don't think menu system could have them.
And if you add a sub menu, you can have Toggle buttons and checkboxes in them too. (Again I don't think it was possible in a menu)

One of the most interesting aspects of controls on a ribbon, is that they can have a super tip, something that traditional menu system lacked. (at least with this quality). A super tip can be a help file or a complete explanation of how the control works. A super tip can be multi line, and styled with html.


View attachment 115302

However, some applications use custom add-ins or third-party tools to enhance the ribbon functionality. These add-ins can provide more advanced features, such as displaying images or even GIFs when hovering over controls. This involves programming with the Office Add-in framework, which allows developers to create custom UI elements and behaviors.
Check the following gif. A mouse over a control, shows a clip on how the control is supposed to be used.

View attachment 115301

View attachment 115304




That is the exact way a ribbon works.
Most of our databases have 4 user defined tables (tblRibbons, tblTabs, tblGroups & tblcontrols) that is joined to a users level table.
On each login, a function reads the preferences and privileges of users and reconstruct the ribbon's XML according to their preferred language. Their ribbon contains only the buttons they are allowed to use.
Adding new tabs, groups or controls is done only by adding a new record to one of the tables. We don't need to go through an xml file with more than a thousands lines, search for an specific control to edit, delete or add a new control.

When you login to one of our databases, the menu can be one of 8 possible languages. After login to FE, a function with less than 50 lines of code, reads the controls from a query with above tables joined, creates the necessary xml code that only contains the controls you are allowed to use, in your preferred language, and sets this XML as the application's ribbon.
What else do you need? You only add controls to the table, nothing else.

I think I've shared a sample database there and I don't repeat it here, just check how a dynamic ribbon works.

I can't remember how I used to add a menu to a database, so for anyone who remembers I have 2 questions: (genuine question)

• Were you able to have a multi language menu? For example when a French logs in to db, all the menu change to French, or to German for someone who is more comfortable with German than English. Was it possible?
• Could you hide some menus or sub menus for some users with less privileges?

I find the ribbon issue is that the icons are just too big. A drop down menu was a few pixels high to start off. Dropping down a 10 option menu only used a little screen space.

How do you provide a sub ribbon, and how many options can it contain. Is it a vertical structure, or another horizontal structure?

As an example I find it a real pain to add controls to a form from a ribbon, because not all the controls are visible, and the icons are so clunky.

 

[DickyP]

I'm not surprised when someone new to Access or ribbon talks like this, but when experts here insist on preferring using traditional menus over ribbons, I'm simply shocked. No offence, but if anyone thinks the traditional menus were better and more useful than current ribbon, I say you don't know how to use a ribbon.

Whereas I would say you never really understood menus. Ribbons are merely intrusive, inflexible menus.

You can't put Ribbons where you want them, you can't have floating ribbons to name but a few of the inflexibilities of ribbons.

In a ribbon, you can add Checkboxes, Toggle buttons, Textboxes, Combo boxes, Galleries and Split buttons which I don't think menu system could have them.
And if you add a sub menu, you can have Toggle buttons and checkboxes in them too. (Again I don't think it was possible in a menu)
(at least with this quality).

All these you can do on menus and you can build them as you go if you wish. To be honest after 17 years of Ribbons they have been refined down to be far less intrusive and to work far more like menus did. And their usage far better suited to Access than to Word and Excel where their implementation is spoiled by the what is included where and with what. In Word for example, as supplied, to effectively use tables you have to go to three different tabs!

And my biggest personal gripe with Ribbons in Word was it forced the OED to abandon their Add-in because they couldn't commit the resource to a complete redesign. I enjoyed having a real UK dictionary spellchecker and reference, rather than Microsoft's flawed American view of UK English.

However, as I said when I stared this - the ship has long since sailed. I still have Office 2003 on my Laptop and if I'm in a hurry to create Word documents I use this and subsequently save as .docx etc.

 

[KitaYama]

How do you provide a sub ribbon,

As far as I know, there's no sub ribbon. You can have as many ribbon as you like, but no sub ribbon. Ribbon has tabs. you can add as many tabs as you like and control them from your forms and classes.

I find the ribbon issue is that the icons are just too big. A drop down menu was a few pixels high to start off. Dropping down a 10 option menu only used a little screen space.

The height of overall ribbon is fixed. But you can use two types as of controls on ribbon. You don't like the large controls, you can use small controls. See bellow image.

Is it a vertical structure, or another horizontal structure?

This is the main problem with those who are not familliar with ribbons. Recent monitors are wider. So the point is to put items horizontally, because you have more horizontally space in your monitor than vertically.
If you insist to go vertically, (which ruins the purpose of using a ribbon) you have two options. Using menu control, and button group control. You can use one or both as many as you like to create something similar to a traditional menus.

But it ruins the purpose of using ribbon. In a ribbon controls are visible to user and they can interact with these controls easily. Why you insist on hiding your controls deep in several layers of menus and sub menus? Why not putting them somewhere that can be reached easily?

 

[KitaYama]

All these you can do on menus and you can build them as you go if you wish.

As I said, I don't remember the menu and how it worked.
Can you show some images of a menu with checkboxes, textboxes or toggle buttons?
I'd like to see a floating menu as well if possible.

thanks.

 

[gemma-the-husky]

As far as I know, there's no sub ribbon. You can have as many ribbon as you like, but no sub ribbon. Ribbon has tabs. you can add as many tabs as you like and control them from your forms and classes.


The height of overall ribbon is fixed. But you can use two types as of controls on ribbon. You don't like the large controls, you can use small controls. See bellow image.


This is the main problem with those who are not familliar with ribbons. Recent monitors are wider. So the point is to put items horizontally, because you have more horizontally space in your monitor than vertically.
If you insist to go vertically, (which ruins the purpose of using a ribbon) you have two options. Using menu control, and button group control. You can use one or both as many as you like to create something similar to a traditional menus.

View attachment 115310

But it ruins the purpose of using ribbon. In a ribbon controls are visible to user and they can interact with these controls easily. Why you insist on hiding your controls deep in several layers of menus and sub menus? Why not putting them somewhere that can be reached easily?

Well, I think they can be reached easily in a menu system, but you can't see everything at the same time.

For example, I built an enormous sales order processing system with hundreds of forms. If somebody wanted to enter a sales order they didn't need to be looking at the product and sales unit management area, so there was one menu tab for sales orders, and another for table maintenance, another for customer and customer branch maintenance, and so on.

Probably 20 or more forms in some of those sections, so not just one sub menu, but a hierarchical tree of sub menus.

Why would you want to see all your menu options at the same time? You don't see all your data at the same time. In fact you hardly ever see all the data in a single table. You don't see every page in a website at the same time. You have a navigation system that helps you find the correct page.

 

[KitaYama]

refined down to be far less intrusive and to work far more like menus did

The purpose of ribbon is not to work like menus. The purpose is to create something that can interact with the user and application. It seems you're determined to compare ribbon to menu, not looking for more possibilities (and maybe sacrificing some functionalities). Did you see my gif above?