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.
Related
I have designed a SSIS project and deployed it to SQL server and also created the job to run on daily basis but its giving me this error when executing this as job (doesnt give any error within VS):
There is this CLSid in this error message but there is no application associated to it in
--> Component Services -> Computers -> My Computer -> DCOM Config
But this CLSid is registered inside registry editor
About this particular task on which this error is occurring: This is a script task which is modifying and deleting the un-wanted rows from the excel file in which I am trying to write SQL table data.
Script task code looks like this:
I have been working for hours now trying to fix this problem but no success. Kindly guide me how can I fix this issue. If any other information is required related to this project, please let me know....
Doing Excel automation in a SQL Server agent job is totally unsupported and probably won't work.
To have even a ghost of a chance of making this work you'll need to run a real desktop session on the server and automate Excel in that. Excel expects a real user to be logged in with a full profile. And Excel has failure conditions where it displays a popup window, which you'll need to be able to access via remote desktop.
You can read and write Excel files on a server with the OpenXML SDK, without actually having to run Excel. There's also a wrapper library called ClosedXML which you may find easier to use than using OpenXML directly.
tl;dr;
You need to install Office (Excel) on the server AND ensure that you install it in a manner that mirrors the SQL Agent's expected bit-edness. Default for Agent is going to be 64bit, default for Office is still 32 :(
Error guessing
You have a script task that uses the Office interop libraries to delete some rows (2 through 11?) out of a spreadsheet.
You have Office installed on your machine and therefore you have the libraries installed. Excel still has COM based "stuff" in it, thus the interop and errors shrieking about the CLSid, registry, etc but that's likely just secondary errors because there is no base "application is not installed" exception to be thrown.
If Office is installed, then ensure your agent execution model matches the version of Office. If 32 bit Excel is already installed, don't potentially break everyone else's stuff by uninstalling and reinstalling as 64 bit, just got the Advanced section of the SQL Agent Job Step and check the 32bit box.
Once all that's done, then if you're still getting errors but new ones, then the existing comments mentioning permissions may come into play - it depends on where the Excel document actually exists (on the computer where SQL agent can access vs on the computer where it cannot vs networked drive)
Good luck in not finding people on the sanctions lists.
I have written a VB.Net application that uses an SQL Express DB file containing a single table and a handful of stored procedures.
I have successfully built and exported the application to my VPS.
The problem comes when knowing what to do concerning the database file, there is a wealth of stuff online but not specifically to suit my needs.
I plan to use LocalDB on the VPS but being commandline - it is hard to know if the scripts that I have run have been successful after creating an instance , starting it... etc,
I want to keep installation requirements to an absolute minimum on my VPS machine and (in time other end users machines)... hence using LocalDB and not SQL Express
So, what do I have to do on the VPS to enable my application to connect to the database.. ? This was simple when it was Access - (supply the MDB file and run the AccessDatabaseEngine(redistributable) - job done)
The connection on my devt. machine runs as expected.
The connection string in my code is:
Const strSQLConnection As String = "Data Source= (localdb)\v11.0;Database=SoccerTrader;Trusted_Connection=True"
Can anyone help please.. this is driving me around the bend.. surely it cant be that difficult..?
===========================
I have found the following in an MSDN blog which says:
Database as a File: LocalDB connection strings support AttachDbFileName property that allows attaching a database file during the connection process. This lets developers work directly with databases instead of the database server. Assuming a database file (*.MDF file with the corresponding *.LDF file) is stored at “C:\MyData\Database1.mdf” the developer can start working with it by simply using the following connection string: “Data Source=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyData\Database1.mdf”.
================ ADDED 12th June =====================
OK, this is really bugging me now... I have read around this till it is coming out of my ears and nothing specifically seems to target what I am trying to do. All the blogs I read refer to installing / running SQL Server and changing permissions etc.
As I have mentioned I am using a VPS and propose to use LocalDB on the VPS to access a simple/small database file for a VB.Net application I am writing.
This is the story so far.
1) I have built a working prototype on my development PC and connected using SQL Express to a database file SoccerTrader.mdf - no problem.
In the Visual Studio Project properties I have added a requirement to the project that checks for SQL Server ..and if it is missing, installs it...
2) I install the project on the VPS and as expected SQL Server 2012 LocalDB is installed .... see here..
3) I have copied the SoccerTrader.MDF and SoccerTrader.LDF files into "C:\BESTBETSoftware\SoccerBot" on the VPS
4) for practical reasons given the problems I am having getting this to work, I have implemented an inputbox for me to specify the connection string when the application runs.... the connection strings I have used give the following...
1]: http://i.stack.imgur.com/i2tro.png
I have not changed any file permissions on the development PC and the database state is NOT read only....
So, the question is where do I go from here...? What have I missed.. why is it not working..?
I have managed to sort the problem.
Seemingly, the connection string I was using was OK. It was my error handling that wasnt 'clean' enough. It transpired the connection was being made on my VPS but when the application attempted to update the table , the directory I had created and put the MDF file into, would not permit write access.
I moved the MDF into the C:\Users\Public\Documents folder and all works as it should.
You have to specify the full path of the Db file with folder name/ip-address
Box was corrupt and was cleaned up and operational. Now, SQL Server will not connect to my db. I checked services and found that mssqlserver, SQL Server agents won't start. Gives error
Cannot connect to local server
They are set to automatically start, but manually starting gives the same error.
I cleaned his box with this recipe that I use successfully on dozens of computers. All other software is running fine. His box also had a failing disk so I xxcloned (XXClone.com) his disk to a fresh new disk. I believe the cleaning is an unrelated issue, but whatever it takes to fix it we are happy to try. I know many people with this SQL Server issue, and over the years have fixed it a few ways, but I am tight on time, so I suggested he get help here.
THOROUGH BADDY CLEAN. Clean a Windows Machine without Formatting it or losing Data
STEP 1
If Ransomware or some baddy is taking over our MBR or Partition so you cannot escape it, and cannot run safe mode, the ICE Ransomware being one of many examples.....
http://www.bleepingcomputer.com/virus-removal/remove-ice-cyber-crime-center-ransomware
use a empty USB stick and HitManPro (the free version will remove)
http://www.surfright.nl/en/hitmanpro/
STEP 2
Reboot in Safe mode with networking by rebooting and holding down F8 key. None of this will permanently fix your computer unless you are in SAFE MODE w/ NETWORKING
Download RKill and run it
Download ComboFix from BleepingComputer.org and run it
Download SmitFraudFix and run it
Download AntiMalwareBytes to catch everything those did not
I can clean any machine no matter how badly infected with these tools in safe mode. Will keep recurring if attempted in Normal Mode. Safe mode is the key.
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).
I've long been a fan of Stored Procedure Keyboard Accelerators, as described in this article. When we moved from SQL 2000 to 2005, though, and from Query Analyzer to Management Studio, the handling of the arguments changed. In QA, comma-separated arguments were automatically read as two separate arguments. In SSMS -- at least for me -- it's being read as one argument, with commas in it. Similarly, if I pass in a single argument with single quotes in it, I get a syntax error, unless I escape the quotes (' -> ''). In the article linked above, the author implies that this should not be the case for SSMS, but even with her exact example, comma-separated arguments are still being interpreted as one argument on every SSMS installation I've tried it on (3 of them), running against every SQL Server installation I've tried (4 of them).
E.g., typing the following into SSMS,
Person,4
then selecting it and running the shortcut, I get the error message "Invalid object name 'Person,4'.
Does anybody have any idea how to fix this? Does anybody even use these shortcuts? I've Googled this problem several times over the past two years, and have had no luck.
Edit: May be an issue with a specific build of SSMS. I have a follow-up post below.
I had never tried this until I read your question and then read the article you referenced, so take this with a grain of salt.
That said, I am able to get the process to work on my computer using SSMS, and I am also able to duplicate the error you described.
To get this to work as expected I created the sproc in the master database, assigned the keyboard shortcut and restarted SSMS. I then typed the databasename.schema_name.table_name in single quotes followed by a comma and then an integer value (the sproc I tested was the GetRows sample in the article). I was still connected to the master database.
This worked without incident.
To get the same error that you mentioned, I removed either the reference to the schema name or database name and received the same error you did.
Perhaps you need to add the database name and schema name before the table name?
Tim's suggestion didn't solve my problem on my development PC, but it did convince me to try again from a different PC. When using a different PC's SSMS to log into the development PC's database and trying exactly what Tim describes, I'm having the same behavior Tim describes.
I was also able to re-replicate the argument parsing issue on the other PCs I had tried in the past. I'm hoping Tim can let me know what's the version and build number on his SSMS installation, because my current theory is that the problem is just from the specific build that my coworkers and I have on our dev PCs -- the version string is "Microsoft SQL Server Management Studio 9.00.1399.00". All of our installs of that version took place well over a year ago, so I don't know that I can trace back what disk it's from.
The one that is NOT having the problem is actually our development server, which has "Microsoft SQL Server Management Studio 9.00.3042.00" installed. I don't know if this might be something I can make go away by patching or something, but it currently looks like 1399 reads the entire selection as a single argument, while 3042 does some pre-parsing. I've also recently found that when I pass in a string that contains "--" (comment token) in 3042, everything after the "--" is ignored, while in 1399, it's all included in the first argument.
I am using SSMS version 9.00.3042.00 as well, which probably explains why it is working on my machine.
Agree with Tim. I have just upgraded to SQL Server 05 sp2 and I confirm that this bug gets fixed.