on 06-09-2021 4:51 PM
Hi guys
I can't create a relational connection to an Excel file shared from an Azure folder.
The BO I'm using is 4.2 SP05 patch 02 installed on Windows 2012 R2.
So far I have successfully created other relational connections to Excel files shared by file servers. To do this I have always used the Windows 32 bit ODBC driver for Excel (version 14.00.7248.5000) and then selecting "Excel 12.0" as the "database version" in the DSN configuration. Then, in the Information Design Tool, I use the network layer "ODBC" and the "database" MS Excel 2007 and everything is ok.
To configure this shared folder from Azure, I ran a power shell script (provided to me) that maps the share as drive Z. The script basically runs the following two commands:
cmd.exe /C "cmdkey /add:`"<BLAHBLAHBLAH>.windows.net`" /user:`"<USER>`" /pass:`"<PASSWORD>`""
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<BLAHBLAHBLAH>.windows.net\<SUBFOLDER>" -Persist
I can see the unit Z in the VM's resources and I can navigate through the folders. So I set the ODBC DSN to point to the file on the newly mounted drive but, when testing the relational connection I'm getting the following error:
I downloaded the excel file locally to the BO's machine and had the ODBC DSN point to him and, obviously, everything is ok.
I also tried copying this Excel file to a shared folder from another host on the same network and again, by pointing the DSN-ODBC to it, the relational connection works.
So I'm wondering, maybe there are compatibility issues for BO in accessing shared folders from Azure? Anyone have information?
Let me know, thank you very much.
One thing to consider is that mapped drives don't exist if a user isn't logged in to the system. So you need to make sure that you map it for the service account that runs BOBJ.
However, I think you will probably need to ask this question in the Azure forums since you can't successfully test the ODBC connection to the file. Since this happens before any report tries to access the data, it's more of a Microsoft question.
-Dell
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Dell
thank you very much for your answer.
Obviously I mapped the shared folder on the local unit Z, with the user with which BO runs (and it is also a local administrative user).
I was wondering, however, since the mapping, at the operating system level, seems to have gone well (I see the shared files and I open them without problems) and I also have the possibility to select these files as sources for ODBC DSNs, if maybe there were some compatibility problem with BO or maybe some special option is needed to mount the share so that it is also accessible from BO.
Hi everybody
thank you for your answers.
SAP support confirmed that the shared folder mapped as logical unit are not supported (look at SAP Note 1342998)
So I am working with the Azure management team to solve the access by UNC that, in my case is not working.
Most likely the problem is about the authentication on Azure resource.
I'll keep you posted.
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just to clarify - I did not said anything about "not supported", I said the test showed that its not working. I was not aware of the KBA 1342998
Assuming this is a universe connection, in order for it to work in BOBJ, you need a 64-bit ODBC connection configured. For the IDT or Designer, you need a 32-bit connection. If you have the Client Tools installed on the same server as BOBJ (NOT a best practice and not supported when you move to 4.3!) you'll need to have both types of connection with the same name.
Also, which Excel ODBC driver are you using?
-Dell
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
72 | |
8 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.