I originally wasn't going to comment at all in this thread. But I thought there might be some value to doing so. We'll see.
There are, naturally things I want. Functionalities I'd like to see.
But I can't really comment on certain items that actually are being worked on in a coming Access version.
And some items fall into that category - and others there are reasons that they won't happen because of what *is* happening - and other items I just don't feel the need/desire to comment on. (So no inference can be drawn on the items I don't discuss in the following points - just to make that clear
)
I'm glad someone reiterated the distinction between Access and the DB engine.
We need to remember what we're asking to be improved.
Bear in mind that, yes, ACE (I'll call it there here) is owned by the Access team - but it's now the database engine for *Office*.
There is only so much investment that's ever going to be put into this.
(Because of the alternatives that MS has to push, SQL Server, Sharepoint...)
I think it does us good to focus on things (and make a big noise to MS about) that have a real shot of being included.
So they aren't lost amid the burden of some white elephants.
But this speaks to the point (near the end of the published list - but I'll mention it first)...
>> make Access much more robust with regards to networking and provide error handling for networking issues
I think everyone would like to see ACE become as robust as possible.
I'd imagine most would sacrifice new db engine functionality in favour of this but it would have to be quantifiable. Can you imagine the fuss as the first reports came out of a corrupted db in some "new robust" engine format. People would be looking for it - it would be under a microscope for quite some time. Would those people be appeased if MS responded "well it's better than it was" lol
>> Bound treeview and listview controls
Yes - effectively more native data controls (which these would then have to become).
Less dependence on ActiveX in general is only a good thing.
Access excels in it's native data controls with strong default binding functionality.
It's essentially unique in that regard. Let's see it even stronger.
>> Ability to show different image for each record in a continuous form
Depends how you work it.
If the path is defined for each row then 2007 already supports recordsource bound Image controls.
>> Restore the new look and feel in 2007 back to 2003
Nah. Just never going to happen. MS are committed to the Ribbon.
It's spread throughout Office and beyond makes it near impossible to backtrack.
(No - I don't love it, and really dislike the Nav pain. Sorting, filtering great. But too limiting a
list after the using whole, sizable DB window for so long).
>> easy interface to integrate ribbon use instead of the XML fiasco
IMO (and this is my opinion only) this could only have been the result of a time constraint in the development cycle.
But, as has been pointed out by some in the past - if you want to feel your vitalness as a developer and separate yourself from users... what better way than needing XML to customise your menu interface ;-)
>> Editable crosstabs
Really?
But crosstabs are transformed aggregate queries.
Aggregates aren't (and by definition can't be) editable. I don't see how this works. Are we talking about Crosstab
like forms?
>> Retain formatting in SQL view of query, allow commenting
Oh don't even get me started. lol
I've been on for this for so long now.
Commenting I could live without but it would be nice... but the parser MUST leave my SQL alone.
A bit of colour, nicer formatting and SQL tools would be nice.
>> Drill down into sub-queries in the QBE
I could do without this.
IMO if you're writing subqueries then you're probably SQL literate.
The QBE would have to become soo complex. Do we allow for corrolation? Sub-sub queries?
>> Give *real* paramaterized queries/prepared statement a la Oracle/MySQL/MS SQL
I just can't see MS spending large amounts of time on this for the reasons I outlined at the start of this post.
Default values for declared parameters in ACE might be a nice start...
But then without conditional statement execution there's only so much we can use those for (as common methods of optional parameters, without using dynamic SQL in VBA, in Jet add inefficiency).
>> Adopt the Excel/Word macro paradigm (using VBA) and institute a macro recorder
I think most suspect this isn't going to happen. Would that be true?
Access is somewhat unique in that its interface is only an intermediate stage in the purpose of the application.
When you're working in Word - you're working on a Document.
In Excel - on a spreadsheet.
But of course, the Macro recorder disables clicks during those times - to increase predictability.
Access has unpredictable use coming out of its ears
>> Invoke the QBE within VBA and format SQL from QBE into VB ready string
An interesting idea actually. But ultimately it's a time saver for us isn't it?
I'd rather keep spending that time and acquire new things that Access simply can't do as yet.
(Similar feelings Re Word integration etc).
>> Provide Application Events
Again form based workarounds exist. But I agree - the Access application object offers no events at all whereas other Office apps do.
However - while we're talking wished for new events here? I'll offer one...
BeforeCurrent
(raised prior to navigating away from a record)
>> VBA commands for *everything* that you can do in the frontend, like splitting database
Well, to take that particular example, that just started life as a Wizard that a member of the Access team wrote and implemented.
It itself consists of several commands.
>> Ability to turn mde into exe
As old as the hills this one.
Do we reckon it'll ever happen? I don't see why it will myself.
It'd be a big old bloated EXE anyway though - and would negate the potential of just using an existing Access install (and offering a small file size instead).
Unless we're talking about an EXE format that *still* required Access to be installed to run.
>> Use different registry keys for different versions of Access so that running multiple versions doesn't cause problems
I'd say general installation, distribution and multiple install issues all together need work.
The time lag between 2003 and 2007 is just not acceptable (despite the SP1 improvement).
>> Make Access completely separate from the rest of MS Office, instead make it an Add-On to Visual Studio
I was actually responding to this point of Banana's in some other thread recently - but lost the page before sending and really couldn't face typing it again.
Fundamentally - I can't see this happening.
It might if Access was near being binned - and as a last ditch effort to get some more use out of it, this was persuaded as a last alternative.
I love Access. (No surprise there).
I think it's a great development tool for database applications - and yes, for serious developers.
Where Jet starts to fail us as we SQL Server (and others) as an excellent choice... and (as developers) we can make it all sing and come together with robustness, power and control. (Sometimes by some convolution rather than default functionality - see many points in this thread ;-).
Great.
Cool!
But that's not why Access exists.
It was created - and it remains to this day - as the leading desktop database application in the world.
It's the database that MS want office workers the world over to reach for and use for tasks that they really shouldn't be using Excel for anymore. To allow them to access and work with data from multiple sources in a way that they'd have no hope of doing so otherwise.
Yes we, as developers, want loads of cool toys. (And I do think we were somewhat overlooked in 2007 - but for reasons).
Many of the things introduced have been attributed as functionality for core users - not developers.
Ummm... yeah.
I'm not happy about it of course, I want developer toys!! ;-) But it is what it is.
If the millions of users using Access for their office work (and let's not forget - asking questions of us online) are why it still exists - then I just have to accept both the balance of user Vs developer toys with each release and that Access is part of Office - for office workers and within those contraints. (e.g. VBA, ACE, Ribbon).
Selected other items would I like to see...
Better Report binding (recordsets, PTs etc).
Some better server DB integration tools. (Deliberately vague on that one - but I think it will do Access good if it doesn't crawl too deeply into bed with just SQL Server - a la ADP - but increases integration more and more).
I'd imagine we'll see managed code added progressively into Access.
I don't see VBA dissappearing in a poof and as the smoke clears VB2010 (or whatever) sitting there in its place.
But hey. Primarily - as long as Access keeps going.
You can't win a race if you're not still in it.
Cheers.
)
