When in Design View on a form with a tab control, if I change the tab control's 'Use Theme' flag to Yes, then that Access process increases CPU usage by 30% and power usage (as shown in Task Mgr) for the process goes from "Very low" to "Very high" - and it stays there. If I save the form and then design it again, the CPU/Power stays normal. But if I change the Use Theme back to No and then to Yes, the CPU/Power goes up again (while in Design View). And, if I try to close the form after changing the Use Theme to Yes without first saving the form, Access just freezes and requires ending the process via Task Manager.

I recreated the issue with a form that had only a single control, that tab control, on it.

Access for Microsoft 365 MSO, 16.0.13426.20270, 32-bit

Currently, if an existing INSERT INTO query has a problem with an underlying query (if there is an error due to a renamed supporting query or table name, for example), the Query Editor inserts new "phantom alias names" into the QueryDef for each column.
So, the resulting SQL looks sort of like this:
INSERT INTO MyTable (ColA, ColB, ColC...)
SELECT MyDerivedColA as Expr1, MyColB as Expr2, MyDerivedColC as Expr3…
FROM (from clause with some underlying table/query naming error here)...

My request is that since the Query editor is "smart enough" to introduce those "Expr#" Alias labels when needed due to errors, IT ALSO NEEDS TO BE SMART ENOUGH TO REMOVE THEM when they are no longer needed (i.e. when the underlying query/table naming error is resolved, and the "Expr#" labels only introduce unneeded confusion/obfuscation)!

Once we "cure" the underlying dependent query/table name issue, IF all the SOURCE column names (once again) MATCH the TARGET column names, Have the Query Editor AUTOMATICALLY REMOVE any of the "Expr#:" alias column names labels it finds.

This is my wishlist request.

Since your Access/Office Roadmap now has an alternative SQL Editor on the list, I would like to renew this request, because once we can actually edit SQL with some REALLY IMPROVED tools and can care about SQL formatting and whitespace (and maybe SQL Comments too?), this issue will drive some folks absolutely NUTS when their SQL gets "messed up" with these EXPR# alias names unexpectedly.

Access returns an incorrect record ID when a form is bound to an SQL Server table that has an 'insert trigger' that inserts a record into 'another' table. The record ID returned is actually the record ID of the trigger inserted record into the 'other' table. This is because Access calls SQL Server for @@IDENTITY rather than SCOPE_IDENTITY() when inserting a new record. This particularly affects SQL Server tables that are 'replicated' as these tables have an MS shipped 'insert trigger' on the table for use in replication. We have an MS Support Case # 23043471 where we have had no resolution ...

SIR,

Actually i am working in delhi police department and at local level we maintain data on crime of our district by making small software with many constraints during entry.

  as we have ..you can say constable who dont know computer at all). (at first i taught them basic computer then they get able to feed data as required.). I have made small software in access and  they feed data on regular basis regarding crime.

thereafter through pivot we analyse very easily.

For them to bring data on every now and then to excel and then analysis is cumbersome. earlier they just open drag and drop field or just open pivot to produce analysis .

whole advantage of access is in pivot view. which make it different from other.

please bring it back.
please bring it back in new version