A chance to influence the direction of Access

We use access for RAD - I can do things in it 10 times faster than coding it in vb.net. It has become apparent to me that Microsoft seems to think its used as a glorifed excel. Maybe some do use for that, I have no clue why, but to each his own. I don't see how it should be part of the Microsoft Office Product line personally, especialy since VFP is being droppped I think have a way to migrate our current apps to vb.net model is a major need, and i think many will agree that we all want to get our apps away from the office model and into a complied code. What used to be a very good system has become way to integrated into Microsoft Office and problems arise left and right when people don't upgrade their office systems and have access 2007 runtime with office xp, or office 2003, etc. its too tightly integrated for my liking. And if thats the direction yoru going, you need to provide us with a way to migrate our aps away from it so we are not so tighly integrated and forced into a direction that has nothing to do with the software product offerings of our apps built with access 2007

It's great to see companies actually asking their customers what they want in products. I'm sure some amount of that goes on anyway, but the development tools market is getting overloaded and competing for developer mindshare is becoming increasingly difficult.

I think this is excellent. I used to integrate applications with Access as the main tool as well as develop, automate and electronically distribute reports for the Illinois Department of Human Services and would love the opportunity to become involved in a group to enhance Access' capabilities.

Great to see you guys doing some user feedback to help with the direction of Access, and would love to throw in my 2 cents worth if it is helpful. 1. Access is a great presenter of data, forms are very easily bound and the report writer is excellent. As a RAD environment it is second to none.

2. Data access and binding can be inflexible however. In the past we have had to go through porting code from DAO to ADODB, and Jet to SQL and now the possibility of MDBs and ADPs to ACCDBs.

Where I personally think Access is weak and produces problems for us evolving our products is the runtime binding of data, and this leaves our evolutionary development pathways hindered.

3. All new code we write that is not strictly Office\Access related we try to write in managed code. There needs to be better support in this area to carry us forward into the world of Web Services and managed components. Points 2 and 3 represent, in my humble opinion, weakness but also great opportunities to carry Access into the future. We are more and more dealing with data from different sources and want fast and effective ways to manage and present it using the latest tools. A few examples of data binding issues we face:

Without writing your own CRUD (and therefore losing the aforementioned ease-of-binding) you cannot bind to a disconnected ADODB Recordset as the row-state is not correctly maintained. There is an opportunity here to totally leap frog over this issue and go to Datasets.

In practice binding at runtime to even a connected ADODB recordset also does not work for anything except the most basic form and query.

Access does not correctly recognize identity columns in multi-table views in SQL2005 so these are not updateable so avoiding table access permissions in your database seems impractical.

These issues become more as acute we (and everyone) write more and more managed dot net code.

Already we run into issues of handling ADODB objects with ADO.NET objects and wanting to span transactions over both etc.

Also if you could bind forms natively to XML or dot net Datasets then most of the above issues go away. I agree with M. David Matney about the productivity of Access as a RAD environment and we want to be able to maintain and evolve our products without doing anything rash like throwing them out for dot net forms etc (while also having an easier path to go there if needed). Suggested solution, looking at improving the delineation of Access the presentation layer vs the data layer, and increasing the generic handling capabilities of the Data Access Layer. Access stopped being a combined mash of data and presentation when MDBs stopped being the default mode and we started using SQL Server, so cleaning up a few of these loose ends would be awesome. Some examples of coding platform issues we face:

An issue for us is runtime cominterop because it is inextricable related to product evolution using managed components.

Due to dll-hell inherent in COM (and therefore VBA), we have taken to latebinding any managed components we use in VBA so that we don't have to rely on our cominterop interfaces in VBA and this has worked brilliantly but it does cause our productivity to suffer due to the lack of consideration of managed components so I don't know if there are options to look at improvements there. Let’s face it though, these would only be a stepping stone to a managed development environment anyway.

Dealing with ADONET data kind of falls into both camps I guess, interop and more generic datahandling. These are just a few of the areas that we face to maintain and evolve our access applications and try to keep them current and viable. We love Access but we need the tools to interact with the rest of the IT framework out there such as web services and dot net framework components.

I may post on my views on what would be good in the way of new stuff later, but there are some important corrections to be made to 2007. For myself (and quite a lot of other developers according to discussions I have had), the main things to put right are:

1) Give Access some decent security, i.e. not just a database password (even though the 2007 password is so much stronger than in previous versions). We need the per-object and per-user security that the old workgroup information file-based security gave (though the new one should have the robustness that the new database password and encryption has). All the blurb that came out from Microsoft about security in Access 2007, since it was so tied in with security in the rest of Office 2007, almost completely missed the point. My customers are not overly worried about viruses in Access (has there ever been one?), but do need granularity. Giving a lowly clerk the same level of access as an MD is, frankly, laughable.

2) Make the ribbon movable. With the trend towards wide screens, taking up space at the top of the screen is daft.

3) Do something about the Navigation Pane, e.g. allow multiple columns. For a developer it is naff. The old database window was so much easier to use to find your database objects. In case that all sounds rather negative, let me say that there are lots of good things about Access 2007. Stuff like 1-3 above spoil it though.

Zac,

This is not relevant to this particular post on the blog, but 1) Thanks for all the information that you are posting. The blog has taken on a really new lease of life and lots of useful information is being posted. 2) Thanks for the Interactive Access 2003 to Access 2007 command reference tool. It is a great help (didn't manage to read the relevant blog post in time to reply there). 3) Thank you for the time and effort you are putting into the discussions with people asking questions and making comments here. Alan Cossey

I love Access for managing data. I use it for bulk updating and reporting.

I am missing a way to publish my databases/applications to SharePoint without needing Acces for the end-user - something like a combination of InfoPath and Access in one product.

The ribbon MUST go, we MUST be able to create applications in the next version that have nothing of this new interface, UNLESS we want to use it. The new interface artefacts are a complete disaster except for people that just dabble with data like they currently play with data in Excel and Sharepoint. We have dumped all development in Access 2007 and will NEVER support this immature product. The next version MUST also expose the underlying structures in the inane COMPLEX DATA on the relationships window. If the next version is less RELATIONAL than Access 2003 then goodbye.

We use Access 2007 and are having many problems with running reports based on queries that get data from an Oracle database through ODBC. We have used both the Microsoft and Oracle drivers to link. Some reports run without problems and others take 10 to 15 times as long to run as they did on Access 2000. It does not help to convert the files to 2007 format. What is the question that I should be asking?

vtj: Have you tried minimizing the ribbon before you run your reports? We've got some known perf issues in RTM that will be fixed by SP1.

Thank for the suggestion. Unfortunately it doesn't make any difference. Two questions: When will SP1 be released and is there a better group to discuss this issue? Thank You again!!

See my post @ blogs.msdn.com/.../do-you-sell-and-access-application.aspx.

I desperately need you to do the following: - FIX OLD BUGS!!!

- forms: incremental search (even for combo-boxes!)

- reports: automatic reports based on Form's Recordset (with grouping, totals, saving report settings, etc.); will send you some screen-shots of my A97 solution

- reports: selectively print a page of a "duplex-designed-report" (with page-breaks) using a non-duplex printer, see "Duplex printing" @ microsoft.public.access.reports (Dec 28th 2006 16:28) by Vladimír Cvajniga

- queries: double-click a query-window in design view should open an appropriate query in design view

- forms: achoring columns

- documentation: missing DoCmd.RunCommand commands documentation (SysCmd too)

- developer extension: support for more languages (I desperately need Czech!)

- VBA code composer (wizard - like in Access 97).

- make some research on database corruption and (finally) fix the MDB-project-corruption bug; if you are not able to fix the bug: think about storing project objects in ASCII-files instead of MDB to prevent corruprion

- create EXE instead of MDE

- forms: add a pure container control (and some shapes, too)

- enhance TabControl to become a true TabControl: - a tab should become a container for all controls including TabControl incl. .Move for all its components at once

- enhance OptionGroup so that it becomes a real container incl. .Move for all its components at once

- in new versions: new options should default to deafults of previous version!!!

- bring back A97-help system; A2002 was user un-friendly with many blank screens !!!

- enable column-locking in multirow forms (same as in datasheet view, see FrozenColumns Property)

- international versions: missing documentation of original English names (properties, menus, ...); it's very difficult to search for an appropriate help without correct translation

- change object size & font size according to screen resolution; don't forget bound & unbound pictures

- enlarge Access system windows so that they can display more than 4 rows of anything (selecting folders, etc.)

- enlarge controls in Access system windows so that they can display full path for long file names

- enhance ActiveX-list-tool

- help should include all topics, basic & advanced; all topics should explain functionality in detail !!! See VBE Property in A2002: help doesn't explain what is VBE !!!

- table designer: put all the stuff in one row so that there's no need to switch between fields (multiline) and tabs

- enhance documentation, eg. RunCommand, SysSmd, ...

- enable PDW internationalization!!! I desperatelly need Czech install for our customers in Czech Republic!!!

- translate VBA environment & help to other languages (Czech is preffered)

- form-design: double-click coud open code module in default event procedure

- desperatelly missing zoom in design view

- forms - export to XLS: exclude unbound controls placed in form's header/footer

- code: more rows for properties, events

- enhance compatibility among different versions of Access or Access RunTime on one PC

- enhance error handling; add error number to each error message box; tell us where exactly an error occured (which form/report/module, which sub or function)

- remove brackets from main Access window, eg. This is my application - [Some text here]; it's UGLY

- forms/reports: add a property SaveFilterOnClose (boolean)

- forms/reports: remove that stupid "save everything on close"-behaviour; do it as they do in VB - they never save dynamically changed forms

- options form: make Set Options strings selectable

- exact error identification !!! (form/report control event property, class module, function or sub name)

- add a tool to handle possible errors (see Total Access Analyzer, www.fmsinc.com/.../index.html)

- forms/reports(?): add Reposition event (for main Access window too)

- missing an easy way to get measures of scroll bars and record selector (and maybe some other items based on system metrics)

- edit: add a possibility to put an expresion and evaluate it on exit, eg. =45*2 equals 90

- enlarge MDB maximum size; 2GB is not enough in this modern era... 100GB shold be enough for another 10 years ;-)

- completely remove AutoCorrect since it makes Access BUGGY and UNSTABLE

- add interval keys

- add -1 to OrdinalPosition for non-existing member

- help: A2002 help is a crap as you may know... I'd appreciate working help with no blank screens - tree structure projects, ie. from main project with common functions I can open a subproject (and then subsubproject, etc.); projects join in memory Main.mdb (or mde): Call SubProject1.mdb (or mde) in a subfolder SubProject1; return to Main when SubProject1 is closed Call SubProject2.mdb (or mde) in a subfolder SubProject2; return to Main when SubProject2 is closed etc. plus a catalogue functionality (paths stored in external Main.cat MDB), ie.: Call SubProject2 from SubProject1; return to SubProject1 when SubProject2 is closed for tree projects see PC FAND: www.alis.cz/.../index.jsp (Czech only; they have EN version of PC FAND) PC FAND is a DOS relational database system

Simon Francesco wrote: "Access does not correctly recognize identity columns in multi-table views in SQL2005 so these are not updateable so avoiding table access permissions in your database seems impractical" ??? I don't have any issue between Access and SQL2005 Identity... Bye

- Zoom in report design mode is my Chimera!

- Shapes in forms and reports

- really Office compatible Reports (export in Excel or word)

- visual dependencies in database form, forms and related queries, tables and dependent queries, and so on. Best would be a grafical interface than Relations.