Hello,

I want to be able to copy master files from DEV to PROD without changing anything in them and appears I can do this but I want to stop the users being able to change the && variable values.

Is it possible to set an && variable in edasprof and not allow the user to change it?

Background :
I want to set &&DB and use it in the master file and acx for the SQL Server database name (&&DB.dbo.tablename one database is DEV, one is PROD (both databases within the same SQL Server instance if that makes sense)), database tablenames are the same in DEV and PROD.

I think I will want to use a similar method for the CONNECTION within the acx via a variable from the master file and give the adapters different names in PROD and DEV (again the &&CONN names will be set in edasprof)

Hope this makes sense, if any other suggestions for acheiving the same or better result happy to hear them.

Regards

This message has been edited. Last edited by: FP Mod Chuck,

I wouldn't mix environments honestly. You're opening up a can of worms you'll wish you hadn't in time. I promise. lol

Otto

A lot of customers will have a separate fex where global amper variables are set and then do a -INCLUDE of that fex in the edasprof. I have seen the use of using them for the CONNECTION and DB but as Cool Guy has cautioned be careful to not mix the environments.

Hello,

Thanks for input.

I will try to clarify what I am saying. I am in the situation where we have one SQL Server instance (think this is correct terminology here) and have one database called Dev and one called Prod. As far as I can see when I copy a master file / acx from Dev to Prod (these are separate environments I think you would term them, totally different boxes I believe) then I will have to go into the master file and acx's in Prod (after they have been copied across) and change the reference in the acx to the Database(Prod rather than Dev), just checking if what I am saying looks correct.

Regards

Normally an acx is pointing to a adapter, let's say "datawarehouse". On the reporting server this adapter points to a database. So on your DEV environment to a DEV database, on Prod to a Prod database. If you use the same schema, you can freely copy mas and acx to other environments without any changes.

There is ineed a possibility to set everything in the acx and mas dynamic and populate with &&. You can protect parameters in the client with:

 <SET> variable_name (protect)

but this only works for parameters that are send from the browser.

In your case I would try to keep same schemanames. If you want to have flexibility in the schema, db table, or db type, then use the && parameters and set them in a mfd profile, don't feed them from the client.

If you use the same Connection Name in the adapter properties in both Dev and Prod (e.g., SERVER_A) then the CONNECTION information in the .acx file won't need to be edited after copying over the .mas and .acx files and there would be no need to set &&DB.

Sounds like a good approach Craig, thanks for your help.

Frans thanks for your advice too, I appreciate it.

I think what has confused me a bit is that I am trying to copy master files to Dev (that are copies of Prod master files, people want to work on changing them and the data structures in the database and testing results).If I just copy a master file from prod to Dev that should work fine using Craigs methodology I think.

But some of the Dev master files should be pointable to Prod data (to save us setting up routines to copy data every day as well). I guess I will set up an adapter in Dev pointing to Prod and change the connection in the acx for those master files. It is probably a no-no to do that some people will say, I thought I might be able to do it with the Database name in our scenario.

I am trying to tie this in with planning how to limit access to end users so they cannot access data they shouldn't so will raise a focal point on that now but for this one thanks for your help, I reckon you have answered my question.

Regards

otto,

my advice is to not connect dev to prod. There should never be any reason to do this. It is a security risk for one, not to mention the possibility of run away queries and other issues that arise when developing off of production data.

I don't understand why you would need a routine to copy data to dev. ever. This seems to me to be just a bad design. At that point, you might as well not have a dev environment at all and just work directly in prod. Also something I don't recommend by the way.

The question of which WebFocus instances connect to which databases could depend on who is doing the development in your environment. For my first 10+ years in WebFocus we had only one WebFocus instance, so naturally it connected to both development and production databases.

We now have a development WebFocus instance, which is also able to access both development and production databases. This allows us to run reports off of live data in the later stages of the development process, so that users can evaluate the report against live data. The same idea applies during WebFocus upgrades. I wouldn't want it any other way!

In our case, we don't have non-tech people developing reports to cause problems with production database performance. . .