Access 'features' that should be deprecated

[isladogs]

Hi

Over the years, there have been many complaints about useful Access features that MS in their 'inifinite wisdom' decided to deprecate.
For example:
- pivot tables / charts
- dBase support (now restored)

Recently some are angry that Web Apps are now being dropped with no proper alternative being available.

On the other hand, there are a number of features which I think SHOULD be deprecated as they have little real benefit & cause lots of problems.

At the top of my list would be things like:
- attachment / calculated datatypes in tables
- lookup and multivalued fields in tables
- split forms and navigation forms

I could probably add others, but do other forum users agree.
If not, which Access 'features' would other users like to see scrapped and why.

 

[plog]

LAST & FIRST in SQL and DFirst() & DLast() in VBA

Actually, deprecation alone is too nice for these 4 things. I suggest bludgeoning to death with a crowbar.

 

[static]

I still hate the 'new' Office tool/menu bars and the database window. So I'd go back to the old ones.

Don't think I'd get rid of anything though.
There have always been 'bad' ways of doing things and there are plenty of things I'd never use.
I'd never use DLookup or Memo fields but how many databases would removing those break?

 

[CJ_London]

Calculated fields are available in SQL Server and Oracle, but not MySQL so far as I know. They are called computed columns. But you still can't upsize them.

I would like to see the default setting for access to be 'open exclusive'. And you can only change a db to multi user if there are only tables and queries. No forms, reports or modules. Or at least a big fat warning of the consequences of sharing a front end. That would at least cut down on the number of corruption issues caused by not splitting and/or sharing the front end.

I did put up a suggestion about it recently here

https://access.uservoice.com/forums...rovide-a-default-setting-to-open-db-exclusive

It does get looked at by MS and some suggestions are adopted with relatively little support

 

[gemma-the-husky]

I agree with all the above.

captions, too,

Mind you, I never use any of the "features" mentioned.

 

[isladogs]

Do you mean captions for table fields?
They can make datasheet headers more readable and don't affect functionality

My list was for items that cause lots of user issues whilst offering little to justify their existence. So in the voice of a Dalek ... EXTERMINATE...

 

[static]

Funny thing is, I miss the security features... even though I never used them because they were a PITA to set up and maintain. Access just seems...lesser without them.

 

[The_Doc_Man]

The old low-level security features were nice conceptually but I agree with Static. They were not the easiest things in the world to set up and often triggered security traps that were better handled by making the forms smart enough to disallow the involved actions in the first place.

I don't know that I would absolutely get rid of them but I would sure like to make them a bit better controllable up front - the "layout" rectangles for wizard-built forms and reports are totally a PITA. If there were an option - even at the level of File >> Options >> Current Database to tell wizards to not use layout rectangles, but just let the twips fall where they may...

 

[Galaxiom]

Do you mean captions for table fields?
They can make datasheet headers more readable and don't affect functionality...

That is an illusion. It doesn't work like you think it does.

Although the Datasheet View might look like the table with the Captions as headers, what you are actually seeing are Controls and Labels formatted to look like a table.

Implementing captions on the table fields causes the Form Wizard to use those Captions instead of the fieldnames as the Label Captions. Exactly the same happens with a Single Form or Continuous Forms.

There is no inherent dependency on the field Captions. You can edit the Label Caption property to show whatever you want, regardless of the Caption Property of the table field.

This system works fine for a novice developer that isn't interested in using VBA. It is an absolute nightmare when writing code because the fieldnames can only be seen in the design view of the table, making the simultaneous visibility of the fieldname and data quite impossible.

In my opinion, field Captions are the worst of the worst features in Access.

 

[isladogs]

That is an illusion. It doesn't work like you think it does.

Although the Datasheet View might look like the table with the Captions as headers, what you are actually seeing are Controls and Labels formatted to look like a table.

Implementing captions on the table fields causes the Form Wizard to use those Captions instead of the fieldnames as the Label Captions. Exactly the same happens with a Single Form or Continuous Forms.

There is no inherent dependency on the field Captions. You can edit the Label Caption property to show whatever you want, regardless of the Caption Property of the table field.

This system works fine for a novice developer that isn't interested in using VBA. It is an absolute nightmare when writing code because the fieldnames can only be seen in the design view of the table, making the simultaneous visibility of the fieldname and data quite impossible.

In my opinion, field Captions are the worst of the worst features in Access.

Thank you for your opinion Greg.
As this entire thread was about users' opinions, I didn't feel the need to reply until you raised this point again in another thread

https://www.access-programmers.co.uk/forums/showthread.php?t=294753

However I am fully aware how datasheet view works and of the role of captions in Access

With regard to captions, I agree with the point you raised if you are trying to understand databases created by others.
However, for my own databases where I will obviously know my own naming conventions, I don't see it as an issue.

That is my opinion - it is neither right nor wrong.

However, I suspect you will not like part of the article on Allen Browne's website where he sets the standard properties for all tables at startup.

'set standard properties for all linked tables

'Purpose: Properties you always want set by default:
' TableDef: Subdatasheets off.
' Numeric fields: Remove Default Value.
' Currency fields: Format as currency.
' Yes/No fields: Display as check box. Default to No.
' Text/memo/hyperlink: AllowZeroLength off,
' UnicodeCompression on.
' All fields: Add a caption if mixed case.
'Argument: Name of the table.
'Note: Requires: SetPropertyDAO()

As you can see from the above, amongst other things, Allen sets a caption for all table fields.
He adds a space before each capital letter in a field name. For example:
- LastName => caption = Last Name
- VehicleID => Vehicle ID etc

Unfortunately Allen Browne's website is currently down so I can't give you the exact link - the article is 'StandardProperties' on the DAO functions page

Hopefully the website is only down temporarily - I have already emailed him to check

EDIT:
The normal link is :
http://allenbrowne.com/func-DAO.html

Whilst that server is down, the temporary link is http://new.allenbrowne.com/func-DAO.html

 

[kevlray]

Access should disallow object (fields, table, etc.) names that have spaces in the names, special characters, etc.. I believe there is an ANSI standard somewhere.

 

[isladogs]

I agree but loads of existing databases would be broken if that were the case including some of mine.

Some of you may be interested to know that Daniel Pineault has created a utility to check databases for reserved words (or characters).
Its on the DevHut website:
https://www.devhut.net/2017/06/21/ms-access-reserved-word-checker/

I ran this recently on my first production database & was horrified by the 2900 examples it found. Hopefully I've got better over the years since then....

 

[RuralGuy]

Thanks for the link Colin. Only 2900??

 

[isladogs]

Only 2900??

Actually no - it hadn't completed checking when I wrote that
The real answer is 3644 from all objects (tables/queries/forms/reports) so there's lots of repetition in that number

Every combination of special characters ?,%,#,~, &, *, spaces and apostrophes
plus reserved words like Tag, Year, Caption, Name, Date, Alias etc ....

It also picked up As, Is & In as output fields from one crosstab query.
These were school subject abbreviations so not 'my fault'!

The checker also picks up fields like DateCreated and Dummy both of which I thought were OK.

However, I think the field name '% 3+ A-A*?' takes some beating for excessive use of special characters! Can anyone beat that?

Yet it still works 'beautifully'

So, with apologies to a recent poster whose naming convention I described as 'horrible' (and got slated by plog & Minty for doing so), its clearly a case of

Do as I say, not as I do

Just looking for a slice of humble pie ...

 

[Minty]

I can't believe I slated anyone over a naming convention

Especially when I'm still dealing with a main table field called [Stock Code / Part Number] on a weekly basis....

And I did think it was genuinely horrible, but at least they had one

 

[isladogs]

Minty

I'm sorry but your answer clearly has excessive use of emojis


I tried to add more but got this forum error:

You have included 11 images in your message. You are limited to using 10 images so please go back and correct the problem and then continue again.

Images include use of smilies, the BB code tag and HTML <img> tags. The use of these is all subject to them being enabled by the administrator.[/QUOTE]

That'll learn me!

 

[CJ_London]

one of the longest field names I ever saw was along the lines of


'estimated value after discount of 20% as of the same month last year'

and that was in a tabled called

'estimated values after discount for last year'

needless to say, came from an excel spreadsheet

 

[RuralGuy]

I'll let you know what my score is on my first system and it will probably beat your score.

 

[Minty]

I'll run this tomorrow for a giggle.

The first "system" I wrote was 20 years ago and completely macro driven. And obviously I didn't have a clue (still don't to be honest, but better at winging it now).

 

[RuralGuy]

My system was done in 2002 with ac2002. I never learned how to use macros so I guess I'm stuck with code. Let's see, that would be about 15 years ago. Wow, how time does fly. It is still in use today.