Should Microsoft combine Excel and Access into 1 product?
The more I think about it the more it makes sense. This is another developer feature post btw – I think I would like Access in my Excel as a feature please. No offence any Access fans reading this- feel free to think of having Excel as a feature in your Access (would that be a step forward??).
You could choose a forms based structured data project (ie Access) or a free form unstructured project (Excel), or something in-between (the new bit).
Heres some reasons why I think it might work
- Complex reports are hard work in Access, easy(er) in Excel.
- Excel doesn’t really do relational data, Access/Jet does
- I reckon there is a lot of commonality already underneath
- Some big horrible workbooks could be neatly replaced with well structured data and calculations that are defined once and used many times.
- Have you got any others?
Whats in it for MS?
- Boost credibility of Excel as a development platform
- Reassure those users who wonder what the impacts of SQL Express are on Access long term future
- Internal cost savings?
- Create a best of breed desktop analysis/business intelligence application (I would leave the precise description and title to Microsoft’s wonderful marketing department of course)
- Demonstrate a massive commitment to reducing spreadsheet hell.
- Others?
I would have preferred closer database integration than the new 1 million row limit in 2007. In fact I suggested they reduce rows to a couple of thousand and improve db integration as soon as I heard.
What do you think? and why? would you buy it? would you use it?
cheers
Simon
Smurf on Spreadsheets 
Wednesday, 21st February, 2007 at 1:23 am |
If you want a 4th generation language, use one. Add a grid control if you must.
As for limits, Excel 2007 provides many times more columns (fields) than Access 2007 but many times fewer rows.
A built-in version of SQL.REQUEST would go a very long way to providing much better database functionality in Excel.
Microsoft already provides Analytical Services for SQL Server, so they already provide what many would consider an industrial-strength business intelligence platform. Are you suggesting a merged Excel-Access as a toy BI platform rounding out the product offerings?
Wednesday, 21st February, 2007 at 1:58 pm |
I would love to see some kind of hybrid Excel/Access product, just make it easier to take advantage of Access’ superior query database abilities. My main work, and skill is, in XL, but I do have to jump over to Access to create queries that can not be performed with XL’s built in light weight query tool. XL2007 does add more rows which helps with flat file DB situations, but Access is required for relational DB needs. I still find that I have to export data back into XL in order to create reports. I know some of my jumping from Access to XL is because I just don’t know how to do the same thing in Access but some things are just easier in XL. After writing this comment and thinking about it, I guess what I am saying is that it would be good (for me at least) if Microsoft would add an industrial strength relational query capability into Excel. But why would do that when they can get me to pay for two products instead of one.
Wednesday, 21st February, 2007 at 2:34 pm |
I am not a fan of unnecessarily increasing the functionality, and de facto the complexity, of applications, especially when integration can work well enough.
It is very simple to connect Excel to an Access database, and the beauty of it is that this can evolve to something greater at a later date, say for instamce that the database is so good the company wants to make it an Enterprise database, to be accessed by other apps.
I do not see the need or the benefits I am afraid.
But I do agree that 1M rows is not a good idea, that will inevitably increase spreadsheet hell. I don’t think that the hybrid would stop spreadsheet hell anyway, some would use the Excel side, some the Access side, regardless of the best solution, because that is what they are more comfortable with.
Wednesday, 21st February, 2007 at 4:23 pm |
First of all, cards on the table, I hate Access. I use it to create tables and relations, embed SQL in MDB files so that I can call them like (a poor wo/man’s) stored procedure from Excel and/or VB6/.NET, but otherwise I don’t touch it. I certainly don’t go near its horrible forms or under-powered reports. If I want to create a numerical reporting front end to a database I use Excel, if I want an admin front end or a summary front end I use VB6 and an appropriate reporting engine if required. I wouldn’t mind at all if MS integrated JET more closely into Excel (as a plug-in option?) and scrapped Access altogether, but I know some companies that use it as a front end extensively. Ych!
I’m interested in “Boost credibility of Excel as a development platform”. Why do you think MS are/would be at all interested in this? 80% of Excel users are creating shopping lists! MS is much more interested in going after this market (which probably doesn’t realise that it would be much better off using Works + Powerpoint), than in pushing Excel-as-development environment. That’s the reason for the &*^%ing ribbon and the stripping out of easy customisation!
Wednesday, 21st February, 2007 at 5:57 pm |
I agree with Bob. I don’t see the need to roll these products into one and increase the functionality and complexity of them both. I think that would end up with more half baked semi-databases than well designed ones. Let’s face it, in some ways it is too easy to build in Excel, which is what gives rise to the spreadsheet hells that we see. By increasing the complexity…
Personally, I’m happy to connect to Access from Excel with ADO and pull/push data back and forth with SQL. My favourite projects that I’ve ever worked on do exactly that, and they work quite well for my purposes. The reporting capabilities in Excel are easier to work with than Access (IMHO anyway), but Access is superior for storing relational data.
I’ll work with them in tandem, but I don’t see the need for them to become one.
Wednesday, 21st February, 2007 at 6:33 pm |
Point taken on increasing the complexity, although complexity is in the eye of the beholder of course. A few more menu options versus auditing 10,000 unique formulas, I would go for more menu items everytime.
I’m thinking of allowing non VBA users some of the ADO type power that programmers take for granted.
Just a thought – I have no idea if or why MS would entertain this or any other suggestions, but if we were to reach some concensus on a few features they might seriously consider them. Or not.
cheers
Simon
Wednesday, 21st February, 2007 at 6:56 pm |
I agree that the two Programs should not be combined, you would probably end up with the worst of each instead of the best of both and compromises everywhere.
I have been using Excel and Access since they were first sold, (Visicalc, Lotus, DataMaster and Dataease before that) and I think that Excel is one of the best Programs ever. Not that I am particularly Brilliant with either.
But when it comes to anything other than a simple database Excel can’t hold a candle to Access.
I now spend my Retirement days helping people with Access Databases.
How many of you guys who can’t get on with Access, prefering to do Forms and Reports in Excel have actually spent as much time and effort learning Access as you have learning Excel.
I didn’t realize that were Form and Report Wizards in Excel that produced them for you.
Does the Excel wizard create Reports with Sorted Grouping, with sorting within the Group and with Subtotals and grandtotals etc?
And Excel Subforms mmmm?
Have you got “Reference” Books. been on courses?
he big weakness of Access is Graphing, Microsoft Graph is very hard work compared to Excel.
Wednesday, 21st February, 2007 at 8:42 pm |
wowow there!
I’m suing Simon for using my TM! I have thought Access and Excel should merge for years! (well at lest 8 months!)
I think Ken and Bob are seeing it too much from there perspective maybe?
“It is very simple to connect Excel to an Access database”
How? With VB, but only a few % of users can do this Bob! How many awful Access DB or monster Excel SS have we seen? 90% of users don’t understand DB, and don’t want to, SW should help them – I think better DB features in Excel could do this…
“and the beauty of it is that this can evolve to something greater at a later date, say for instamce that the database is so good the company wants to make it an Enterprise database, to be accessed by other apps.”
True. However i think this is just moves the development down the line a bit? Also it might actually save time as only X% of these Access/Excel DB will get migrated, so the total dev time could come down…If you see what i mean.
“I don’t see the need to roll these products into one and increase the functionality and complexity of them both.”
I don’t think it will increase the complexity – windows v’s dos? Also the complexity is just rearranged – it’s all in one app (although loads of people will not see it!) but it might even be less complex!
“I think that would end up with more half baked semi-databases than well designed ones.”
Yes. I agree with that – well not necessarily more, but a lot of half backed ones – just like there are now!!!!
– Need less to say it will never happen…
“……….That’s the reason for the &*^%ing ribbon and the stripping out of easy customisation!”
too true… still access might go?
Wednesday, 21st February, 2007 at 9:34 pm |
Having been a corporate computer trainer my observation went somewhat like this. If you could handle a typewriter then learning Word was pretty easy. If you could handle a calculator (and knew primary school math) then learning Excel wasn’t hard. However nothing prepared students for relational theory.
One of the first lessons I learnt as a developer was never show a client an Entity Relationship model (sure, it’s in the Appendix but don’t have a conversation around it). You should have seen their eyes glaze over.
Also remember those MFC (fax, print, scan, copy etc in one). Too often they were superior in one function and below par on the rest. Most products excel (bad pun intended) by doing one thing really well.
I’d also agree that 1M rows is a disaster waiting to happen. The good thing about 64K rows is it forces users to realise that maybe Excel isn’t the best place to store all this data and that they should be using something else. The worst Access solutions I’ve seen were developed by end users who erred in two ways: they didn’t plan out the solution and they didn’t apply sound relational principles. Merely copying a worksheet to a table wont increase your reporting flexibility.
Rob: Sorry to hear of your distaste for Access. I think it’s a great tool (for certain jobs). It’s excellent for prototyping – I’ve worked on several projects where an Access backend was migrated to SQL after proof of concept had been tested (for a fraction of what it would cost in a SQL Server environment). Forms with linked subforms – what can I say, bliss. And for small group environments it’s a great solution.
Ken: For some reports Excel is superior and for others, Access’ structured reporting paradign works well. The major bummer is report editability – often users want to be able to copy portions of a report, to powerpoint for example.
Simon: Great post. Good pot stirring.
Cheers – Marcus
Thursday, 22nd February, 2007 at 3:53 am |
Simon,
Great post… Of course I would like the two integrated…
What I would really like is to have Excel as the major player…. If I thougth I am storing too much data in a file… I would like a option to save the file as an XLD xl Database file…. A file with no row and colum limits…
The relational part of the data base can be handled easily in a well structured excel file….
Regards
Sam
Thursday, 22nd February, 2007 at 11:53 am |
I forgot one important point in my previous comments. Security.
Excel doesn’t have much!
At last Access does provide for it, although as we all nothing is “Un-breakable”.
Thursday, 22nd February, 2007 at 1:05 pm |
A Osborn – I agree that each tools has its strengths and weaknesses, and often some combinations is best. I like that Excel has no security, I think that is right for the uses I have for Excel.
Ross – what happened 8 months ago? (and you can have the idea if you can explain how Amazon has TM’ed ‘Real Name’ – http://www.amazon.com/gp/help/customer/display.html/104-4882983-2021509?ie=UTF8&nodeId=14279641)
Marcus how many people have you met that said ‘oh, Access, yes I did a course on that but don’t use it because I don’t understand it’? I’ve met loads sadly, you’re probably right its the ER diag that does it!
Sam – see my next post for my initial thoughts.
Cheers
Simon
Friday, 23rd February, 2007 at 10:54 pm |
Simon,
“Different tools for different purposes” is my guide and it does not include a hybrid “Access/Excel” tool.
Kind regards,
Dennis
Sunday, 25th February, 2007 at 7:26 am |
Dennis (and others) is right. Excel is built for analysis & presentation purposes; Access is designed to be a RAD db environment.
The two cannot fully meet as this would compromise the effectiveness of both, and has the same merits as merging Powerpoint with Excel. The sum of the parts, is greater than the whole.
Anyone who isn’t too confident with Access/Excel interoperability should take just a little time out to explore it. It’s bark is much worse than it’s bite! :-)
Monday, 26th February, 2007 at 6:13 am |
Quite a different mix of views.
I wonder what those against the idea said when VBA was added to Excel in the mid 90’s?
‘Spreadsheets for users, C for developers, VB/VBA is just a compromise no use for either!’? ‘It will make it too complex’?
Tim wouldn’t you like a RAD db with great analysis and presentation facilities (no code required?). I would, and I know a lot of users who might benefit too.
I can certainly see difficulties, but thats just implementation detail in my view.
BTW I like Access, and have delivered many projects in it, as well as migrated plenty into and out of it. This wasn’t meant to be an anti-Access post (just the opposite actually if you consider its position!).
cheers
Simon
Tuesday, 27th February, 2007 at 1:31 pm |
“Tim wouldn’t you like a RAD db with great analysis and presentation facilities (no code required?).”
No problem:
1) Write a query in Access, then use the Excel ‘DB Query’ tool to do the rest
or
2) Write a query in Access using the JET ‘In’ clause:
http://msdn2.microsoft.com/en-us/library/bb177907.aspx
I already use the latter over code, but I’m still not sure what an Access/Excel hybrid could deliver much beyond some extra buttons to make this existing capability more widely recognised? :-)
Wednesday, 1st April, 2009 at 3:01 pm |
[…] integrating SQLite with Excel, datasmiths can have the best of both worlds, familiar spreadsheet front-end combined with a fast and powerful SQL engine and datastore, in fact, everything that MS Access should have […]