As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I have a bunch of code that gets moved from Dev to Test to QC to Prod and each step of the way we have to screw around with changing the access files to match the environment.
Oracle Server 1 contains: Dev, Test, QC
Oracle Server 2 contains: Production
Because we have 3 environments on the same Oracle machine we have to use different TNS Names for each like APP_DEV, APP_TEST, APP_QC and APP_PROD
How can I just reference APP and tell each one what it means in its own environment? There has to be a way to do this.
We have a similar issue with our DB2 environment and having different campuses, so we made the last part of the MFD and access file name similar to what you show, then change the name of the MFD in the code to have and amper variable as part of the name. The only problem is it isn't recognized by report caster, but you can do a -set command,
We use ®ION, so when we're testing it's -SET ®ION = TEST; and so on.
Would that work for you?
Leah
Posts: 1317 | Location: Council Bluffs, IA | Registered: May 24, 2004
The access file must be unique for each environment. It needs to know exactly where to point to, so there is no way around that. What may be possible is to create 4 separate application folders and have each one contain a version of the access file for one of the Oracle environments. This way, when you want to use a particular Oracle environment, just run the procedure in the application folder that has the appropriate access file pointing to that Oracle environment.
Many thanks to Leah's input and hope this helps.
Cheers,
Kerry
Kerry Zhan Focal Point Moderator Information Builders, Inc.
Posts: 1948 | Location: New York | Registered: November 16, 2004
If you remove the CONNECTION attribute in the access file, then WF will default to the first ORACLE instance defined in the server profile. Therefore, if you have a seperate WF instance for each environment, you can set up an ORACLE connection to just the required ORACLE instance, and WF will default to that instance.
"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
Currently we are using about 8 Oracle databases and therefore each has its own conneciton. We set the primary one to the default so we can just leave the CONNECTION blanked out and that works. It is the rest of them that then are the issue.
We used to do an amper-like work around in .ASP for this type of thing but didn't know if there was a way around it.
For example when I have other office analysis that needs to be done across dev/test/prod I can just have MS Access connect to the ODBC data source and change its location but my code never changes.
I guess I was hoping for two layers of abstraction somehow the connection as DATABASE_X and then have that point to whereever based on each environment.
I don't really like the idea of having 4 copies as that leaves the door open to forget updating one. We have done that before on accident and ended up having the query pull some data from one dataset and the rest from another. The only way we spotted it was the performance tanked out as compared to normal since it was getting full datasets and joining in WebFocus.
Forgot to ask that if I do use the variable method will that cause my scheduled reports through report caster to fail or will they still work correctly??