I'm wary that the architecture is really the problem since presumably there would be some wrapper or whatever to get around it, hooking up database data seems to me to be the kind of thing MS wouldn't want to break.
If reinstalling Excel with the 32bit version will work, they would definitely do this, but I don't want to suggest this unless I know it will work (not least because it means getting the IT contractor out).
I managed to get out of the Excel wizard and into VBscript itself, which can see the driver but then it tells me "architecture conflict" and refuses. I can't see it at all if I try to set up a new pivot table. So I find the 32bit one, which shows the driver and I successfully configure it. After lots of head-scratching, it turns out there's two different versions of the ODBC admin tool. At first I couldn't figure out why, after installing the ODBC driver, it wouldn't even show in the ODBC admin tool.
Then they upgraded to W7 64bit and MS Office 64bit. They upgraded the data source software to a new version and after a bit of fiddling I was able to simply point it to the updated ODBC driver and all was well.
This fully automated a significant task for a senior manager, enabling her to do in a click what used to be a week-long task (and avoiding lots of scope for human error to boot). Previously, they had everything 32bit under XP and I set up Excel to pull in data from another (32bit) program, using that program's ODBC driver. I suspect the issue is that 64bit Excel cannot work with a 32bit ODBC driver, but my time and accessibility with the charity is very limited (also, it doesn't help that I have to get their IT contractor to put in the admin password all the time) so I'm hoping someone either knows a solution or can confirm my analysis. I'd doing a bit of freebie work for a charity that's strayed into more of an IT problem than my own speciality.