I am trying to execute a workflow mapping from within Informatica Workflow. The source being MSSQL Server and target Oracle DB. The mapping alike every other mapping seems to be referring to the system's /etc/odbc.ini file rather than the one sitting in $INFA_HOME/ODBC7.1/odbc.ini.
I've tried checking everything but can't seem to understand how this linking is getting established. I did many hit & trials to confirm which odbc.ini was getting referred and it was always the one sitting under /etc/. The bash_profile's variable ODBCINI is also pointing towards the INFA_HOME location.
Can someone shed some light on how or why the system's odbc.ini is getting referred. Any idea on how is it linked?
We need to set two odbc related parameters in unix/linux users bash profile.
INFA_HOME=/opt/infa
ODBCINI= $INFA_HOME/ODBC7.1/odbc.ini
ODBCINST=$INFA_HOME/ODBC7.1/odbcinst.ini
Now, i feel like, your unix/linux user is not able to reach this location or they arent getting exported properly.
Login using the unix/linux user thats running informatica.
Then use more $ODBCINI to see if it has read permission.
Do same for ODBCINST.
Use ssgodbc tool to check connectivity to your mssql server DB.
Related
It seems the question on how to connect to oracle database from UFT/VBscript is asked on multiple forums. In most places, there are answers in bits and pieces, without any one detailed answer that helps user get this information.
I spent close to 6 days to get this working and thus I feel its worth to share all the detailed steps here. The main reason I found this for going wrong is a wrong combination of one or more of below:
Using the wrong driver.
Using the wrong connection string.
Using the wrong terminal to test the code (i.e. 64 bit to test working for a 32 bit UFT)
When any one of the above is wrong, we get a range of errors depending on which driver, connection string and terminal we are using. I encountered:
Provider cannot be found. It may not be properly installed (when using Microsoft ODBC for Oracle)
The 'OraOLEDB.Oracle.1' provider is not registered on the local machine (when tried using oraOLEDB driver)
Catastrophic failure. (when running a working script on 64-bit terminal)
Hope below answer will give you a step by step answer with references, and code examnples to try out your code and get this up and running for you.
It took me 5 days to get this correctly working and although there is information available on internet, its all scattered and leads to multiple directions, which can be very time consuming and frustrating. So to save you from this frustration and also since test data is very crucial for setting up any meaningful test framework, this section is dedicated to making this properly set up for you. Hopefully, you will not have to face the same frustration that I went through in dealing with this!
To make oracle database connection work in UFT, download a 32-bit driver for your oracle database. To do this:
Go to this page (if your database is 12c - if another database, go to that page), https://www.oracle.com/database/technologies/oracle12c-windows-downloads.html
Scroll down and look for "Oracle Database 12c Release 2 Client (12.2.0.1.0) for Microsoft Windows (32-bit)" - If you are working on oracle 12C
Download the zip file "win32_12201_client.zip"
Extract the file and run "setup.exe" from the folder : Downloads\win32_12201_client\client32
While selecting "What type of installation do you want",
select -> Administrator (1.5GB)
Use windows built in account (3rd option)
Keep default locations for
oracle base -> C:\app\client\yourUserID (no space in between allowed)
software location -> C:\app\client\yourUserID\product\12.2.0\client_2
Save response file for your future reference
Install the product
To test if everything went okay or not, open the ODBC connection for 32 bit
Check in the driver's section, if a driver with name "Oracle in OraClient12Home1_32bit" is installed or not.
Now you can run the vbscript for testing database connection by running it in 32-bit command line mode. (Running it in a terminal on 64 bit machine would give you all sort of errors). To do this on windows,
Type %windir%\SysWoW64\cmd.exe in Start Search box.
Change directory to your script location (say cd c:\Users\yourUserID\UFT\Rusty\FunctionLibrary) - If the script is in dir FunctionLibrary
Now you can run the script by writing cscript in front of it -> cscript database-functions.vbs
You should see values popped up from test script.
Connection string format:
https://www.connectionstrings.com/oracle-in-oraclient11g_home1/ (use standard format from here)
Dim connString: connString = "DRIVER={Oracle in OraClient12Home1_32bit};DBQ=yourHostURL:portNr/DBname;Trusted_Connection=Yes;UID=MyUser;Password=myPassword"
Ex (with dummy values): connString = "DRIVER={Oracle in OraClient12Home1_32bit};DBQ=ab12.mycompany.com:1521/ORAB;Trusted_Connection=Yes;UID=pramod;Password=myPassword"
A script that you can use to test this connection is here.
https://github.com/PramodKumarYadav/Rusty/blob/master/FunctionLibrary/test-data-functions.vbs
Or here: https://hoopercharles.wordpress.com/2009/12/12/simple-vbs-script-to-retrieve-data-from-oracle/
Change the connection string to as mentioned above.
Hope this helps and you can save a lot of time and energy in using oracle connection itself to build tests, than setting this up itself.
Having an issue getting a SQL Server linked server to Oracle working while using a tnsnames.ora file on a network share.
If I copy the tnsnames.ora file to the local server, the linked servers work fine. However, we keep the file on a network share. My sql service accounts have read access to the share. I configure TNS_ADMIN system variable to the network share, the linked servers no longer work. I get ora-12154: could not resolve the connect identifier specified. tnsping and sqlplus work on the server. When I use process monitor to investigate further, I see:
Operation: createFile
Result: ACCESS DENIED
...
Impersonating: domain\MyLogin
This seems like an issue, but is maybe a false positive? If a process is trying to impersonate my account and access a remote resource it will fail since we don't have Kerberos configured to handle double-hop.
SQLPlus and TNSPing work just fine with the network share configured.
I've looked at this post and tried the items that seemed relevant, but had no success.
Additional Info:
sqlnet.ora has this:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
I am able to open a file browser as a service account and open the tnsnames file.
I had this same issue while trying to connect a oracle 10g database via my WCF serivce developed in .NET 4.0 framework.
I was having multiple instances of ORACLE installed in my system. So, I modified the ORACLE_HOME to point to the Oracle 10g and it worked.
Also check the following:
Your service name might have an alias, so Make sure that your listener is listening for the same service name that you are using and check for both local and global entries. Check:
$ORACLE_HOME/network/admin/tnsnames.ora
Check your global_name setting with this SQL:
select * from global_name;
Also, Please make sure you add the Key TNS_ADMIN in the registry and create a enviroinment variable with name TNS_ADMIN
Regedit->HKEY_LOCAL_MACHINE->Software->Oracle->RightClick NEW->StringValue and name
Specify the correct path where the oracle is installed for Example
X:oracleproduct32bit10.0.1.0.0NETWORKADMIN
Edit
The below video also looks quite helpful. Please check.
https://www.youtube.com/watch?v=Sec8WG8gQPg
As an Oracle DBA I sometimes have to work with Windows. Maybe you can adopt from my experiences with Oracle on Windows.
Scenario:
An Oracle DB runs under a domain user. I want to restore a database from a backup which is located on a Windows share (sounds like "read" but it obviously isn't). I (or let's say the windows team) did not manage to find the proper way to grant the required permissions.
After many tries, the admins grant "everything" to the entire Oracle server.
Even though the Oracle process runs in a user context we did not find a set of permissions for the user only. Only the permissions for the entire server enabled the restore process to access the data.
From security point of view this is a horrible solution! But maybe it will help you to come closer to a solution (and if so, please share :-)).
I am attempting to use a Packaged Solution for my Access 2010 application that has its backend linked to SQL Server. At the moment, I'm using the .accdb file as the frontend, and I would like to distribute my application to some other Windows computers, but the Packaged Solution does not work. I had the package include Access Runtime, so their version of the frontend is running on Runtime and not full Access. However, once the application makes a request to the backend, the application does nothing, as I am not even prompted for the SQL Password as per usual with the full version. I've read on about including a .dsn file in the package can secure the SQL connection (see here), but going through steps of other tutorials to create .dsn files hasn't led to any results. Would anyone know how to correctly generate the .dsn file or if I've done something else wrong at this point?
(And yes, I understanding using Access 2010 in the year 2019 is almost a joke at this point, but I'm doing this for testing purposes. I plan to completely remake the frontend in Angular in the future.)
One other unrelated note... would it be a better idea to have the frontend hosted as a .html file like through the "Publish to Access Services" process? I did read that Access Services was discontinued last year, so would that not be possible?
Edit: This is not a duplicate of "DSN Less Connection (MS Access to SQL2016)" because A) I want to utilize a DSN Connection, not DSN-less and B) I am not using connection strings in my code to hook up with SQL.
You should be able to just create FILE dsn, link your tables, and then distribute the compiled accDE to each desktop.
However, what SQL odbc source provider did you use? If you use the SQL server ODBC provider, then that is by default installed on each computer.
However, if you linked using Native 11 (or later), then that driver is NOT installed on each workstation by default. So, I HIGH recommend you create a FILE dsn (not a user or system DSN), and link the table using that. (Access will create DSN-less links for you)
And you should NOT be seeing a logon prompt with your application. This suggests you forgot or missed the save password option.
So, I would re-link your tables, creating a new FILE DSN. And if you using the linked table manager, then make sure you check the prompt for new location to force creating of a NEW DSN. If you just re-fresh, then you DO NOT get a chance to click on the save password option during the linking process.
So, what odbc driver are you using? The native 11 or later are better, but they are not installed by default on each workstation. However, CAUTION is required here, since the older sql driver does NOT support the newer datetime2 formats. If you used these newer sql column types, they will be returned as string data types in Access and create a mess of issues.
So, first, I would re-link using a FILE dsn.
Make sure you check the save password during the re-link.
You then compile your accDB into an accDE, and then distribute that. You don’t really need to use the package wizard, since once each workstation has the runtime installed, then a simple copy of the accDE to each person’s computer will thus work fine. There is NO special connection between your accDE and the package wizard. Once the runtime is installed, then any and all mdb, accDB, and your accDE can simply be clicked on to launch + run. So for testing, you can skip the package wizard, and just copy the accDE to the target machine, click on it, and see if it works.
Edit
The prompt and check box during this process is this:
So you have to check that box to save the password. Note that you ONLY get this dialog WHEN you create a new FILE dsn.
I am receiving this error message while creating DB from a .mdf and .ldf files located on a network drive.
Query executed:
create database DatabaseName ON
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf'),
(FileName = '\\gyancluster-sql\g$\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Error
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a
network path that is not supported for database files.
So what is your problem? What is the question? No question there - just dumping a sentence ;)
I mean, without wanting to sound too sarcastic, but you CAN read, or?
The file "\gyancluster-sql\g$\Backup\WSS_Content_DB.mdf" is on a network path that is not supported for database
files.
That is pretty clear, isn't it? It is not supported - for VERY good reasons, btw., until now.
Are you asking us now whether MS lies? No, they do not lie - this is not supported. They REALLY MEAN what they say.
There are ways around (http://support.microsoft.com/kb/304261) but that is it ;)
Do you want us to reword the error message? Maybe into "dude, that wont worx, not cool, see"? Clearer?
Seriously - soudns harsh, but I always wonder why people do not actually READ the error message.
Use DBCC TRACEON(1807) before trying to create the Database.
Also, you can add the linea "-t 1807" to the MSSQL server startup parameters, it will make the change permanent. The command above let you use network storage, but on a reboot you will lose the flag.
You are lucky that the OS is warning you that opening database files directly over a network is a bad idea. Older database api's let you do that with no warning and then network users of that database application are forever blighted with corrupt databases.
If \gyancluster-sql\g$ refers for Local Disk G on the computer gyancluster-sql which also happens to be where the sql service is running, then you really should be using
create database DatabaseName ON
(FileName = 'G:\Backup\WSS_Content_DB.mdf'),
(FileName = 'G:\Backup\WSS_Content_DB_log.ldf')
for attach
GO
Note this remains true even if you are running the script from another computer.
It would still be a bad idea, but you may able to use the UNC names, but only if the service under which sql is running is able to access the share(eg if running under the Domain Administrator account), but that is normally considered an unnecessary security risk.
If you are really trying to store the database on network device, then obviously that means the sql service does need access to the share, so that would be the first thing to check, but you also need to read the Microsoft article which Chris Dickson has pointed you to (ie http://support.microsoft.com/kb/304261) which details when this is supported.
You need to enable the database file over network shared, the following post explain step by step how to do it.
https://blogs.msdn.microsoft.com/varund/2010/09/02/create-a-sql-server-database-on-a-network-shared-drive/
The same post explains the risks to do it.
I hope this helps
Regards
Situation:
I have a program written in VB6
The source code of the program is not available
It connects to a database using ODBC connection string.
The vendor setup a connection name to the database when the program was first installed 6 years ago
My machine crashed, all the settings are gone!
The program vendor is out of business. Even they don't have the source of the program now.
Question:
Can I find the ODBC connection name in anyway?
You can use Process Explorer to catch the connection string your program is trying to open. You can find almost everything a program is doing, and you can filter what information is captured/displayed.
I'm not sure I've understood. What exactly happens when you try to run the program? Is the problem that the ODBC connection string was lost because the settings were lost when your machine crashed?
If so I would try the following.
Look on a backup for the configuration file of the VB6 program. It may be an INI file.
Do you know what the database is? Is it an Access file (*.MDB), SQL Server, or what? You may be able to recreate the connection string from scratch. You might have problems if you need to supply a password.
Are you still in contact with anyone from the vendor? I'd have thought whoever originally wrote the program would be best able to help, and might be willing to do a couple of days consultancy.
Can't you use a decompiler?
You can probably run an ODBC trace and then look in the log file to see what the attempted name was. Run odbcad32.exe and go to the trace tab and turn it on. Run your app and then look in the log file (probably at the SQLConnect call).