Do you agree that products always have room for improvement?
"Every day there are little things in software that we find annoying. Some write books about it, like Annoyances.org, but I thought this site would be more constructive.
BetterSoftwareSuggestions.com is proudly maintained by myself and the developers at SSW."
- Adam Cogan 
Microsoft’s Access Snapshot Viewer is a useful tool for viewing and printing Snapshot files (*.snp). While we can use its graphical interface, it would be good if the program could also be operated using command-line switches, such as ‘/openfile’ or ‘/print’.
Access should automatically build and decompile when the user selects the Compact and Repair menu.
Access needs to have a built in File and Folder dialog so that it doesn’t need to be calling the Office API as it requires a lot of work. It should be as simple as one would use it in Visual Studio.
Dim MyOpenFileDialog As System.Windows.Forms.OpenFileDialog
MyOpenFileDialog.InitialDirectory = "C:\"
MyOpenFileDialog.OpenFile()
One of the problems that Access developers have when they design in a bound environment is that they put combo boxes on forms which show a big list. This is not only hard to navigate once you start showing hundreds of records, it also causes the form to take longer to load, especially when you upsize to SQL Server.
A better option is to include next to the combo box an ellipsis button “…” which pops up a lookup form.
Figure: Developers typically return all records for a data bound combobox field, which can increase form load time and put unnecessary strain on the database
Access should have a button to deploy a report to reporting services, that turns it into an RDL file, deploys and opens it in a browser. We know that the conversion progress may be complicated and that every piece of functionality will not be available, so if you want this function you should be able to set a property on the form that says “Reporting Services Compatible” (i.e. disables some of the features in access to increase compatibility)
On the Forms you want to have an option that allows you to convert to a One-Click Windows .NET Form (which turns the Access form into a .NET Windows Form) and have people use that through the browser. This allows a Skilled access developer to deploy a basic data entry form to the browser and have the enterprise entering data. We know that the conversion progress may be complicated and that every piece of functionality will not be available, so if you want this function you should be able to set a property on the form that says “.NET Compatible” (i.e. disables some of the features in access to increase compatibility)
The form designer should have a property to turn tracing on, similar to ASP.NET 2 (see figure below). Tracing will log all the methods that are called as well as the time taken by each method. This is particularly useful identifying the causes of slow loading forms.
Figure: Turn tracing on through the properties window
If your Access front-end is linked to a SQL backend, you will encounter a large number of errors and unsightly message boxes if the SQL Server connection is closed for whatever reason. Access should be able to recover gracefully from this common problem, rather than bombard the user with dialogs. Read more information about this issue.
At the moment there are the Form and Continuous views. Access needs another view that doesn’t have the navigation buttons at the bottom but instead should have a search form that is bound to table. This allows for easier and more intuitive navigation of large data sources.
We know there is existing functionality to search fields, but the interface is not intuitive and robust enough.
Figure: Bad example – Access’ built in Find Dialog – Not intuitive
Figure: Good Example – A Search Form to view data from a Table – Allows for better queries
You should be able to put the runtime in the folder of the MDE and xcopy it to another machine and it should work.