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? :-)

‘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

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! :-)

“Different tools for different purposes” is my guide and it does not include a hybrid “Access/Excel” tool.

Kind regards,
Dennis

The relational part of the data base can be handled easily in a well structured excel file….

Regards
Sam

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

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?