What are the top things you would like to see in a future version of Access?

[Alisa]

I haven't used 2007 hardly at all, so my wish list is based on what I see in 2003.
VOTE HERE:
http://spreadsheets.google.com/ccc?key=pXVO5qt9gdRIeZ-Nb6tVOWA&hl=en


All suggestions so far, with number of people who voted for each one:
FORMS/CONTROLS/INTERFACE:
-Bound treeview and listview controls, or at least wizards to assist with the loading
-Ability to show different image for each record in a continuous form (1)
-Ability to change color and/or shape of command buttons
-Provide more configuration options to tweak the behavior, even if it has to be done with a CLI, *ESPECIALLY* for ODBC/OLE DB behavior and bound form behavior (e.g. saving early or late, etc) (1)
-Allow for form and control templates
-Better tab control (e.g. transparent ones *and* using Windows Theme for example)
-Corollary: Make sure that Access controls inherits from Windows' controls (I understand that Access controls are just lookalikes... confirmation?)
-Restore the new look and feel in 2007 back to 2003 (1)
-Better integration with BLOB types (sound, picture, and video) with Active X controls
-Provide a means to open a .doc/.xls file directly and define fields for records graphically to simplify the automation and using Word/Excel's native functionalities with convenience of Access's bound controls. (1)
-easy interface to integrate ribbon use instead of the XML fiasco (1)
-Continuous form on a continuous form (1)
-Web integration
-Word properties in Access
-Built in or at least intuitive drag/drop functionality


QUERIES:
-Editable crosstabs (1)
-Retain formatting in SQL view of query, allow commenting
-Union queries in the QBE
-Drill down into sub-queries in the QBE (3)
-Provide a mean to use read-only query as a recordsource for a bound form/report, and a separate but updateable recordsource for inserts/updates. (1)
-Give *real* paramaterized queries/prepared statement a la Oracle/MySQL/MS SQL

MACROS/VBA:
-Completely eliminate macros as they currently exist. Adopt the Excel/Word macro paradigm (using VBA) and institute a macro recorder. Integrate Application level commands into the "macro" recorder (i.e. split a database, etc.). (2)
-Invoke the QBE within VBA and format SQL from QBE into VB ready string. And/or do a direct dump of SQL from QBE to a VB formatted string.
-Provide Application Events (e.g. OnOpen and OnExit for Access environment) (1)
-VBA commands for *everything* that you can do in the frontend, like splitting database, etc., and/or better documentation of such commands if they already exist
- update the vba code when using the command button wizard

SECURITY:
-Better security, restore ULS, provide a hook into logging so we can specify custom logging form or do some extra processing with security (e.g. authenticating for backend at same time) (1)

OTHER:
-Ability to turn mde into exe (2)
-Use different registry keys for different versions of Access so that running multiple versions doesn't cause problems (1)
-Make Access completely separate from the rest of MS Office, instead make it an Add-On to Visual Studio
-Make it fully object-oriented (1)
-Reinforce good programming habits (e.g. have a sane naming convention for starters), controls on form should have a different default name than the field names when created ... maybe using some kind of prefix such as cbo, txt (2)
-Remove the 355 byte limitation (per field) on exporting data to Excel.
-remove/hide certain features which are considered "bad practices" such as lookups at table level
-make Access much more robust with regards to networking and provide error handling for networking issues (5)
-better native database backend
-Triggers

 

[georgedwilkinson]

Union queries in the QBE.

 

[Banana]

If I may, I'd like to change this:

-Make Access completely separate from the rest of MS Office

To this:

Make Access an Add-On to Visual Studio. (To provide a clear upgrade path for front-end clients and provide more scalable solution)

-Provide more configuration options to tweak the behavior, even if it has to be done with a CLI, *ESPECIALLY* for ODBC/OLE DB behavior and bound form behavior (e.g. saving early or late, etc)
-Make it fully object-oriented
-Reinforce good programming habits (e.g. have a sane naming convention for starters)
-Allow for form and control templates
-Better tab control (e.g. transparent ones *and* using Windows Theme for example)
-Corollary: Make sure that Access controls inherits from Windows' controls (I understand that Access controls are just lookalikes... confirmation?)
-Provide Application Events (e.g. OnOpen and OnExit for Access environment)

 

[Alisa]

Good ones!

 

[Banana]

Alisa, I just realized I missed one thing- can I ask you to elaborate on "better security"... what is missing from the 2003 security?

 

[georgedwilkinson]

A couple more:
Drill down into sub-queries in the QBE
Restore the new look and feel in 2007 back to 2003
Better integration with BLOB types (sound, picture, and video) with Active X controls

 

[Banana]

Drill down into sub-queries in the QBE

Excellent idea! Would be a joy to have.

This reminds me of one more thing:

-Provide a mean to use read-only query as a recordsource for a bound form/report, and a separate but updateable recordsource for inserts/updates.
-Give *real* paramaterized queries/prepared statement a la Oracle/MySQL/MS SQL

 

[Alisa]

Alisa, I just realized I missed one thing- can I ask you to elaborate on "better security"... what is missing from the 2003 security?

Well, you can buy a program that will unlock a database password or a user level password for about $20, and it is hard to take advantage of the other security solutions that are out there because you can't turn Access into an exe, which is the only format that a lot of security solutions can protect.

 

[Alisa]

Excellent idea! Would be a joy to have.

This reminds me of one more thing:

-Provide a mean to use read-only query as a recordsource for a bound form/report, and a separate but updateable recordsource for inserts/updates.
-Give *real* paramaterized queries/prepared statement a la Oracle/MySQL/MS SQL

Now I have a question for you can you elaborate on that last one? What is a "real" parameratized query?

 

[Banana]

Wasn't aware of a program for unlocking ULS password; thanks for the note. I already knew that database password was *cough* crap *cough*, and can be easily broken. Guess it isn't the case with ULS.

Parameterized query or prepared statement or whatever the vendors of {insert the RDMBS software here} calls it is basically a superior alternative to dynamic SQL.

The query would look something like this:

SELECT ? FROM ? WHERE IncidentDate=?

To which you can then supply the parameters in order, so say you sent the server this statement:

MyPreparedStatement(foo, bar, 1/1/2008)

The server then uses the variables and fill it in to get the final statement:

SELECT foo FROM bar WHERE 1/1/2008

Now, Access does have parameter queries, but there are limitations that Leigh Purvis pointed out. One point would be to allowing for multiple criteria *and* optional criteria.

Say if I didn't want to specify a incident date but rather search for all possible dates, I could do this:

MyPreparedStatement(foo, bar)

to get the resulting SQL:

SELECT foo FROM bar

Good luck trying to do the same thing with Access's parameter query.

Did that help?

 

[Alisa]

Wasn't aware of a program for unlocking ULS password; thanks for the note. I already knew that database password was *cough* crap *cough*, and can be easily broken. Guess it isn't the case with ULS.

Parameterized query or prepared statement or whatever the vendors of {insert the RDMBS software here} calls it is basically a superior alternative to dynamic SQL.

The query would look something like this:

SELECT ? FROM ? WHERE IncidentDate=?

To which you can then supply the parameters in order, so say you sent the server this statement:

MyPreparedStatement(foo, bar, 1/1/2008)

The server then uses the variables and fill it in to get the final statement:

SELECT foo FROM bar WHERE 1/1/2008

Now, Access does have parameter queries, but there are limitations that Leigh Purvis pointed out. One point would be to allowing for multiple criteria *and* optional criteria.

Say if I didn't want to specify a incident date but rather search for all possible dates, I could do this:

MyPreparedStatement(foo, bar)

to get the resulting SQL:

SELECT foo FROM bar

Good luck trying to do the same thing with Access's parameter query.

Did that help?

Yes, I definitely get what you are saying. I usually just use dynamic SQL when I come up against a situation like that, but you are right, it would be much simpler if you could to it the way you are saying.

 

[georgedwilkinson]

The real issue with Access queries not having real-live parameters is when you're connecting to a real DBMS. Using parameters (?) prevents several operations on the database server and frees up the server's memory for re-use.

 

[Alisa]

Anything else?
This is not a completely idle excercise - I am going to a presentation by someone who is on the Access development team at Microsoft, and he has said that he will listen to our suggestions on the future development of Access . . . so I am going to bring a list!

 

[Banana]

Regarding security:

1) They took out ULS from 2007, didn't they? Put it back.
2) If they *do* put it back, please do provide a hook into logging so we can specify custom logging form or do some extra processing with security (e.g. authenticating for backend at same time)


And for Automation/Reporting:

Provide a mean to open a .doc/.xls file directly and define fields for records graphically to simplify the automation and using Word/Excel's native functionalities with convenience of Access's bound controls.

 

[Alisa]

Regarding security:

1) They took out ULS from 2007, didn't they? Put it back.
2) If they *do* put it back, please do provide a hook into logging so we can specify custom logging form or do some extra processing with security (e.g. authenticating for backend at same time)


And for Automation/Reporting:

Provide a mean to open a .doc/.xls file directly and define fields for records graphically to simplify the automation and using Word/Excel's native functionalities with convenience of Access's bound controls.

On the security: Yes!

Didn't there used to be more integration with other office products, and wasn't there a lawsuit that made them take it out because of their being a monopoly or whatever?

 

[Banana]

Didn't there used to be more integration with other office products, and wasn't there a lawsuit that made them take it out because of their being a monopoly or whatever?

Hmmm....

Am aware only of IE & OS integration lawsuit. Office integration lawsuit is news to me. (and I'm pretty sure that OpenOffice, NeoOffice, Corel Suites has just as much integration...)

 

[Alisa]

http://www.theregister.co.uk/2005/06/07/microsoft_pays_excel_man/

I don't really know too much about it, I found this, which seems to be slightly related . . .

 

[Banana]

I see. Even if that was indeed the case, it doesn't mean they can't do it forever and more; just that they'd have to come up with their own method (and prove that they wrote it from scratch) or just buy the man out (Not to claim that one or other was in right; just don't know the merits of the case).

 

[Alisa]

Yep. Also, I don't know if that is related to the abandonment of the office web controls, which I thought had a lot of potential, or if that was a separate issue.

 

[georgedwilkinson]

Either better remote control commands for or better documentation for low level Access commands. I'm pretty sure that doesn't make sense so here's a for instance.

If I want to split a database using the built in tool, I need direct access to a computer on the network with the database installed to do the split. There is not a command that can be run (that works) in VB that will split the database. I would like it if, anything you can do with the Access "tool" in front of you could also be done programmatically. If that is already a part of Access, then they need to document it and support it.