Which paths should i change when shifting/changing application db, so ETL jobs can continue running?
The answer is I have no idea unless you provide us with details of your current DB connection. Have you defined it in a LIBNAME statement for example? If so please post it.
I have changed the connection on tns file from amlprdtz to amldrtz , but below error comes whenever i run ETL
Can you reach the server amldrtz from your SAS server? Try the Oracle TNSPING command from your SAS server to confirm if the Oracle server is accessible (tnsping amldrtz).
@karume wrote:
I have changed the connection on tns file from amlprdtz to amldrtz , but below error comes whenever i run ETL
Then wouldn't you also have to change the value for the path parameter in the libname statement?
From the looks of it this libname is defined directly within AML solution macro %fcf_run_autoexec();
Which path can i find that?
I don't know where that's stored. My hands-on experience with AML is from years ago and with an older version.
You could run your code with option MAUTOLOCDISPLAY. This will write to the SAS log where a macro gets picked-up from.
If in a Unix/Linux environment you could also just search for the physical file which should have the same name than the macro definition and be all in lowercase.
find / -type f -name "fcf_run_autoexec.sas" 2>/dev/null
I assume that also in a current AML version a lot of the solution macros are pre-compiled with no access to the source code so changing the code might not even be possible.
I also don't know if there are other places where this value is hardcoded and would need change.
I guess the name is either installation default or then gets set in the code artefacts as part of installation scripts.
If you can't find the location(s) for changing the value then contact SAS Tech Support.
This is something which the admins (SAS Admin / database admin) can do.
The best course of action is to approach them
Looks like you are using ORACLE as the back end databases. if yes then change the details in tnsnames.ora.
In a typical case no other would be necessary
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.