Is anyone else having problems connecting Excel 2013 64 bit to HANA via ODBC or ODBO

[Former Member]

This is mainly directed to someone from SAP. I spend the entire afternoon trying to figure out how to connect Excel 2013 to my HANA instance on AWS. I'm pretty familiar with connection MS Office apps to ODBC sources, but HANA is baffling me.

I'm able to get testing the connection to succeed when creating a DSN, or building connections using the various connection wizards in Excel 2013 and have reviewed the post http://scn.sap.com/docs/DOC-30887 on connecting Excel 2010 to HANA.

When trying to connect with either ODBC or ODBO, I get the error that the data connection wizard cannot obtain a list of databases from the specified data source. If I try connecting to HANA using the ODBO driver using the PowerPivot data connection wizard, Excel crashes!

Any guidance on patches would be welcome. I downloaded the HANA client drivers for 64 bit from the HANA Development center link http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/webcontent/uuid/402aa158-6a7a-2f10-0195-f43595...

I'm also using the RTM version of Excel 2013.64 bit

For the host name, I use my Elastic IP address with a colon followed by the 30015 port number.

Thanks in advance,

Bill

[vivekbhoj]

Hi Bill,

I hope you have already installed HDBCLIENTXLS file.

It defines Client for MS Excel properties.

You have to additionally install this file after installing HANA Studio and HANA Client.

I am working with 32 bit Excel 2013 without any issues.

Regards,

Vivek

[Former Member]

Hi Vivek,

I am getting this error, when trying to connect Excel 2010 to SAP HANA. Can you share some details on the HDBClENTXLS file you are mentioning?

I am working with provider version 1.5.14.16.

Best regards

Ralf

[lbreddemann]

Hi Ralf,

the user account you use to logon to HANA does not seem to have permissions to read the SAP_HANA_EPM_DEMO.TCURX table.

Just grant the SELECT privilege to your user and retry.

- Lars

[Former Member]

Hi Lars,

thanks for the hint. I've checked this and the SELECT privilege is granted to the roles of the user account. I've actually been using the SYSTEM user, since I thought this might have top privileges.

Ralf

[Former Member]

Hi Lars,

any thoughts on creating a super user (one who can bring the system to the halt like 777 or admin) thus relieving us from worrying about permissions? if HANA progresses to the level of ECC then security will have its own group of dedicated users who never deal with actual data or developing extensions in the system and are tasked with controlling access only. having this in trial/developer instances seems to be an overkill, unless SAP wants us to beta test security in addition to basis and development environment.

thx,

greg

[lbreddemann]

Hey Greg

I know, I know ... "AS SYSDBA" always was so handy for a developer/admin/hacker...

The thing here really is: it does lead to more bad and good in the end.

Things that worked with this special user suddenly don't work any more once the special privs are gone and it's a drag to figure out what privilege is missing.

So what do I do?

I actually create a user to work with.

I create a role containing basically all system privs/roles except for the ones I really don't see a reason for... (INIFILE ADMIN? rarely used... ).

I assign this role to my user ... that's it.

This user now can create new users, roles, reset passwords, trigger backups, create information models and access XS engine...

All the schemas I build are owned by this user.

All the models are build by that user.

Does this make up a good setup for a development user? Nope.

Is this something I would want to have in my productive dev system let alone the actual production box? Hell no!

But it's useful for playing around and tinkering with the system. Just that.

That's my take on this.

- Lars

[Former Member]

NOTE for anyone looking at this problem. The ODBO driver is working fine since build .48. My latest tests with the relational ODBC driver for build .52 still fails.

[Former Member]

Quick update - since the problem looked like it was an issue with table enumeration, I created a less privileged user account with access to just the tables in the user's own schema. No luck - the good news is that the crash in Excel was able to send a DR Watson report.

Regards,

Bill