SQL is something that I find particularly useful when I am running a database. However, the SQL user interface is very poor in my opinion. It should be more something like the Visual Basic interface, where when you start typing in a formula, then it has a dropdown with all your options and when you select the function from the dropdown, it will show you how to build the formula. For me it becomes very time consuming to have to go online to figure out how the function is built. Also it would be great if it can be colour coded. There should also be more SQL functions that should be made available to the user, like in Microsoft SQL.
Also, being unable to comment directly into the SQL code is something I am finding annoying because I would like to be able to explain to future users what certain pieces of SQL code are for. I would appreciate if you could implement these ideas in the next version of MS Office. Thanks!

Whenever an ITEM such as a heading progress bar is in the Detail section, so if you display the form as Continuous Forms, you will see a progress bar in each displayed record. It will happen whenever a Continuous Form displays more than one record.

The only way to avoid this is to move the progress bar to the form header (or footer) section.

Please refer to the attached design, on the very last page described in microsoft forums.

https://answers.microsoft.com/en-us/msoffice/forum/msofficeaccess-msowindows8-mso_2010/crosstab-query-to-display-all-records-according-to/b98b9372-1a83-402d-b54d-87ca5b7a7407?messageId=c8966d76-2bcd-4a49-a1cc-83cdcf71a483

Either an access development enhancement to enable this would provide more flexibility to create complicated reports.

Thank you kindly.

MS Access's ACE SQL engine continues to run with a variant form of ANSI-89 with some ANSI-92 features while the rest of the relational database world has adopted more recent ANSI standards and at the very least fully comply to the universal, lowest common denominator standard accepted in the industry: ANSI-1992.

Being a highly used, worldwide database for small to medium-sized shops and its popularity with the Office suite, enhancing Access's dialect to industry standards will add value to current and future users including the Microsoft brand. Even SQLite, a similar, very popular file-level database as open-source counterpart to Access, has a richer, more expressive updated SQL dialect.

Such specific features that would greatly enhance the expressiveness, portability, and efficiency of Access queries would include:

ANSI-1992

• Support of other joins - FULL OUTER JOIN, NATURAL JOIN, and CROSS JOIN; with use of USING clause;


• Support of CASE statements as more enhanced, portable version than IIF() especially for nested logic;


• Support of distinct aggregate functions: COUNT (DISTINCT ...), AVG (DISTINCT ...), SUM (DISTINCT ...);


• Support of wildcards operator, %, in GUI rather than * or use of ALIKE or restricted to ODBC/OLEDB queries;


• Support of CAST for data type changes as opposed to the non-portable C-functions: CStr, CDbl, CLong, CDate, etc.;


• Support of COALESCE for handling of NULL across columns as opposed to nested IIF(..IS NULL) or NZ();


• Elimination of the parentheses requirements for more than one JOIN which often frustrate many new users and require the use of Access GUI's Design View to build complex queries;


• Support of ON clause conditions on single table fields rather than joining tables first and then running WHERE.

Other ANSI

• ANSI-1999: Common Table Expressions (CTE) using WITH clause for more readable, maintainable, and less repetitive SQL code than subqueries and derived tables (supported in SQLite as of version 3.8.3, released 2014-02-03);


• ANSI-2003: Window functions using OVER and PARTITION BY clauses to supplant the domain (DSum, DMax, DCount, etc.) functions with more efficiency than correlated subqueries (supported in SQLite as of version 3.25, released 2018-09-15);


• ANSI-2003: Support for MERGE statement for synchronous UPDATE and INSERT needs based on conditional logic.

Other recommendations

• Support of EXPLAIN <QUERY> to allow users evaluate query operations especially use of indexes;


• Support of CREATE DATABASE as opposed to requiring code for creating .mdb/.accdb files;


• Support of CREATE TABLE AS instead of only SELECT * INTO for clarity of DDL action;


• Support of CREATE VIEW AS instead of requiring code with QueryDefs for creating stored queries;


• Distribute the ACE engine (.dll) as a shared object (.so) with CLI (similar to SQLite) for Unix (Mac, Linux) users (e.g., SQL Server 2016/2017 is now supported on Linux).

With backwards compatibility, above changes is a challenge but such features can be integrated with newer versions of the ACE engine (.dll) to be distributed to users, or with add-on patches, or entirely new Access version.

Additionally, though Microsoft strategically intends to keep SQL Server as its flagship database system and upgrading Access may somewhat interfere with this objective, arguably Access can be situated as a complement and not substitute to the enterprise server RDBMS. Rather than advancing Access’ front end GUI features for use as a complement to Excel, consider strengthening MS Access as a standalone, small-scale database engine product.

I have Office Professional 2013.

I have it installed on an Asus Laptop running Windows 8.1.

Also OP 2010 on Windows 7.

I open 99% of my files through "File Explorer" as I have several thousand (files) sorted into numerous sub-folders.

Whenever I open an Access file to check some details and then close it WITHOUT MAKING CHANGES "File Explorer" shows that Access has automatically changed the "Date Modified" to the most recent date and time that I open and then close the file.

This is despite the fact that the last time I may have made a change whether in design or data entry to the file was 2 - 5 years earlier.

This is unbelievably annoying.

Please have the Microsoft programming department make a modification so that the "Modified Date" policy is the same for all Office Professional programs and will only be updated if changes to design or data entries have been made. Please apply this to Access 2010, 2013 and 2016. I like many people have several computers with different Office Pro versions.

I sometimes have several hundred to a thousand files of very similar names and use the Date Modified to sort or get information from them.

Why is it that if you open a MS Word 2013 file and close it without changes there is NO date change to "Date Modified" when you view the file in File Explorer?

or

If you open a MS Excel 2013 file and close it without changes there is NO date change to "Date Modified" when you view the file in File Explorer?

Sometime if you make a change in Excel or Word and then decide against it both programs first ask if you want to update changes and if you say no Word and Excel store the original dates and DO NOT CHANGE THE FILE DATE TO THE MOST CURRENT DATE OF OPENING.

Yet if you open MS Access 2013 and close it without changes there is ALWAYS a date change to "Date Modified" when you view the file in File Explorer?

If a solution currently exists to stop the date from changing when there have not been any changes then I would appreciate knowing how to stop it.

I have gone through the Microsoft Community and other sources and wasted several days to solve this problem but no-one seems to have an answer. In the process of searching I have found many other people frustrated with the date change problem .

Why is there no continuity in Microsofts multiple program designs with respect to this problem.

I have been buying Office Pro & access when it was a separate program for as long as they existed and have always had this problem. I never had this problem when I also used Paradox.

Thank you

The Access 2000 mdb format supports VBA UserForms with normal and parent controls, but all database formats beyond Access 2003 (ACCDB) only render UserForms that do not include Parent controls.

Being able to reuse UserForms across VBA hosts is a very useful way of reusing code and User Interfaces, but a runtime error (Error 75) occurs when trying to render a UserForm in an ACCDB database format, when there is a Parent control (such as a Frame or MultiPage control) present.

Parent controls enable rich functionality and more intuitive UI, but Access fails to render the forms, with an error that suggests that the VBA Project is corrupted.