The data environment I work in has multiple copies of an app...

[Guest]

You can set the global variable for the connector in the server profile using the reporting server console.

[Manoj Chaurasia]

You could also create a MFD profile so it only sets the variable when that master file is used.

[Scott Zak 3]

The data environment I work in has multiple copies of an application database with a consistent schema. I use WebFocus to connect to similarly-named tables in all of the databases through a single master file by parameterizing the CONNECTION attribute in the access file with a global ampersand variable. The variable contains the name of a defined database connection. I can set the connector in the preprocessing code for a Reporting Object and access any of the databases.

When I try to use a parameterized master in WebFocus Designer, the master fails to connect to anything. I dont see a place for preprocessing code.

Is there a way to do this using WebFocus designer

[Toby Mills]

Hi Scott

Ill add in another general idea to go with what David and Chuck already suggested.

If you users access this database based on Groups theyre in, you can take advantage of server side profiles to set the connect strings.

Instead of changing the CONNECTION= attribute with a variable, leave a static CONNECTION name. To make it dynamic, use profiles to switch where that Static name is pointing

For example,

Group A gets ENGINE SQLMSS SET CONNECTION_ATTRIBUTES MAINDB sqlserver.domainame.com/,;groupAdb

Group B would get

ENGINE SQLMSS SET CONNECTION_ATTRIBUTES MAINDB sqlserver.domainame.com/,;groupBdb

So MAINDB would always be the name of your Connect String, but it points to different a different database depending on the users Group.

I dont know if this idea fits what youre trying to do. The idea being to make the Connect String itself change instead of changing the name of the CONNECTION=.

This way - anytime you go into Designer, the connection is valid and alive. For each different sort of user, you would fire their Group profile so the connection string is pointing to the right database.

I feel like Im not describing this very well. Let me know if this seems like a valid idea for you. The plus for it is that your users, because they are members of Groups, will only be able to see whatever theyre supposed to see. Hides all the other connections that you probably currently have sitting in your edasprof.prf.