cancel
Showing results for 
Search instead for 
Did you mean: 

Changed DSN in connection object but reports still use value from old DSN

Former Member
0 Kudos

We're running BObj XIr2 SP4 and have both WEBI and DESKI reports. Most of our DESKI reports have two data providers, one from a universe (header/footer info) and one for free-hand SQL (report data). We are testing in preparation to upgrading all our databases to SQL2005 and have created a new DSN which points to a SQL2005 database to be used by our universe and free-hand SQL connections. We modified our existing connections to use the new DSN and to use the SQL2005 database engine. Our WEBI reports are working just fine and are returning data from the SQL2005 database, but on the DESKI reports the header/footer info from the universe is correct but the report data is coming from the "old" SQL2000 server. If we create a new DESKI report and export it, it retrieves data correctly from both data providers, but the existing DESKI reports, which use the same connections, have the same problem. The new DSN exists on the app server and points to the correct database.

We were hoping that, like the WEBI reports, the changes would be transparent to the reports, but that doesn't seem to be working. Is there something we must do to get the existing DESKI reports to recognize and use the new connection parameters?

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Jim, on the server you may want to remove the following file which stores the shared connections and recreate using Deski pointing to the new SQL server 2005:

"C:\Documents and Settings\<USERID>\Application Data\Business Objects\Business Objects 11.5\lsi\sdac.lsi"

Former Member
0 Kudos

Thanks, George. If we rename the existing file, what do we have to do to re-create it?

Former Member
0 Kudos

Open Deski on the server and select Free Hand SQL as data access and create the new connection there by clicking on the right most database like icon. Make sure you name the connection as current reports expect. This will recreate the lsi file and of course it will only contain the new connection you just created.

Edited by: George Pertea on Sep 11, 2008 10:25 PM

Former Member
0 Kudos

Will that remove all the other connections we've defined for the various universes, etc.?

Former Member
0 Kudos

Jim, yes by removing the original lsi file it will also remove any other shared connections you have defined. Basically this file contains all shared connections defined on the local machine. So if you rename/remove the file and go and create a new Free Hand SQL report you will notice that there no connections available.

One thing you can try if you don't want to wipe out all shared connections by deleting the lsi file is this: Open Designer on the server and go to Tools -> Connections and look for the problem shared connection and delete it. Then you can recreate it there with the same name using the SQL 2005 credentials, just make sure you use the same connection name.

Former Member
0 Kudos

Interesting - So, please let me know if I understand this correctly: If I create a new shared connection using DESKI or Designer on my workstation, it is saved to the server and creates an entry in my local lsi file but doesn't impact the lsi file on the server? If I later modify that connection via DESKI or Designer on my workstation, my local lsi file is changed but the server lsi file is not changed, meaning that any report using that shared connection running through InfoView will not use the new connection parameters but will use the "old" parameters from the server lsi file. If someone then modifies the connection via DESKI or Designer on the server those changes are reflected in the server's lsi file, but if I run a report using that connection via DESKI on my workstation, it will use the parameters from my local lsi file. That would mean that someone could actually delete the connection on the server and I could still run the report in DESKI?

It also appears that the free-hand SQL reports can't use secured connections so I can't by-pass this issue by using secured connections...

I'm assuming that secured connections don't work this way since our Universe connections were modified on the workstation and saved and work correctly.

Former Member
0 Kudos

Your logic seems correct. Also, I believe the connection info is stored within the report that's why when you export to server the report still refreshes without manually creating the connection locally to server. If you want to use a new connection you have to create the connection locally to server (via Deski or Designer), then import your report and open Data Provider and Run the report again using the new connection. Re-export the report. Try that, it should now use the new connection.

George