Archive

Installation of the ODBC driver in Windows 7 is quite simple but there are a few tricks better to know. Here is a step-by-step instruction how to install the ODBC driver.
First of all, you need to download proper files:
– here is the link for Instant Client Downloads for Microsoft Windows (32-bit), for ODBC, you need instantclient-basic-nt-11.2.0.3.0.zip and instantclient-odbc-nt-11.2.0.3.0.zip files (Oracle 11.2.0.3 version)
– here is the link for Instant Client Downloads for Microsoft Windows (x64), for ODBC, you need instantclient-basic-windows.x64-11.2.0.3.0.zip and instantclient-odbc-windows.x64-11.2.0.3.0.zip files (Oracle 11.2.0.3 version)

Which version to choose – 32-bit or 64-bit?
Well, I think the best way to answer this question is to describe my situation. I need to get data from Oracle to Excel. I have on my PC: Windows 7 – 64-bit version, 64-bit Oracle client already installed but MS Office in 32-bit version. So in my situation I had to choose 32-bit ODBC driver. Generally, you choose ODBC driver version based on tool version, that you use to get data from Oracle database.

Anyway, both downloaded files, you need to unzip to THE SAME folder (for example: c:\oracle\instant_client_11), then add the folder to the PATH environment variable:
Then add the TNS_ADMIN environment variable indicating the path to the tnsnames.ora file (in my PC it is c:\oracle\11.2.0\CLIENT\network\admin):
Next, open the command line (Run as administrator) and go to the folder where you unzip ODBC driver, in my case:

cd c:\oracle\instant_client_11

and then – still in cmd, install ODBC:

odbc_install.exe

When successfully, you should get the following info:

Oracle ODBC Driver is installed successfully.

So, right now we can configure ODBC connection: choose Control Panel, then Administrative Tools, then Data Sources (ODBC), then System DNS and then Add, on the list, choose instant_client_11, then Finish and then in the configuration window… wait. You don’t have instant_client_11 on the list. That’s the problem I also had – ODBC driver didn’t appear in ODBC data source.
This is because you use 64-bit ODBC administration panel. If you install 32-bit ODBC driver, you’ll need to use 32-bit ODBC administration panel – run odbcad32.exe from c:\windows\SysWOW64.

So, on the list, choose instant_client_11, then Finish and then in the configuration window add proper data in the Data Source Name, Description, TNS service name (from tnsnames.ora) and User ID.
Then, you can test connection and when everything is correct, save the connection, close ODBC window and enjoy your Oracle data in MS Office tools 🙂

Few notes before, I wrote about finding the HP product number of any of your HP servers using PowerShell. First time, when I tried to do this, I double-clicked a .PS1 file (.PS1 being the file extension for Windows PowerShell scripts), sat back, and waited for the magic to happen.
As it turned out, however, this is what happened:
Instead of running, my script opened up in Notepad. Interesting, but not exactly what I had in mind. Oh wait, I thinked, I got it: I probably have to run Windows PowerShell before I can run a Windows PowerShell script. OK, that makes sense. And so, with that in mind, I opened up Windows PowerShell and typed the path to the .PS1 file at the command prompt. Pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
Why did I get weird error messages when I try to run a script? That’s easy. The security settings built into Windows PowerShell include something called the “execution policy” – the execution policy determines how (or if) PowerShell runs scripts. By default, PowerShell’s execution policy is set to Restricted – that means that scripts – including those you write yourself – won’t run. Period.
How to verify the settings for your execution policy? By typing the following at the PowerShell command prompt and then pressing ENTER:

Get-ExecutionPolicy

Now, admittedly, this might seem a bit severe. After all, what’s the point of having a scripting environment if you can’t even run scripts with it? But that’s OK. If you don’t like the default execution policy (and you probably won’t) then just go ahead and change it. For example, suppose you want to configure PowerShell to run – without question – any scripts that you write yourself, but to run scripts downloaded from the Internet only if those scripts have been signed by a trusted publisher. In that case, use this command to set your execution policy to RemoteSigned:

Set-ExecutionPolicy RemoteSigned

Alternatively, you can set the execution policy to AllSigned (all scripts, including those you write yourself, must be signed by a trusted publisher) or Unrestricted (all scripts will run, regardless of where they come from and whether or not they’ve been signed).
After I changed execution policy settings it’s possible to run scripts. However, there is a little trick that might run you into problems. For example, suppose you change directories from your Windows PowerShell home directory to C:\scripts (something you can do by typing cd C:\scripts). As it turns out, the C:\scripts folder contains a script named script.ps1. With that in mind I typed the script name, pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
I know what you’re thinking: didn’t we just change the execution policy? Yes, we did. However, this has nothing to do with the execution policy. Instead, it has to do with the way that PowerShell handles file paths. In general, you need to type the complete file path in order to run a script. That’s true regardless of your location within the file system. It doesn’t matter if you’re in C:\Scripts; you still need to type the following:

C:\Scripts\script.ps1

Now, I said “in general” because there are a couple of exceptions to this rule. For example, if the script happens to live in the current directory you can start it up using the .\ notation, like so:

.\script.ps1

And while PowerShell won’t search the current directory for scripts it will search all of the folders found in your Windows PATH environment variable. What does that mean? That means that if the folder C:\Scripts is in your path then you can run the script using this command:

script.ps1

But be careful here. Suppose C:\Scripts is not in your Windows path. However, suppose the folder D:\Archive is in the path, and that folder also contains a script named script.ps1. If you’re in the C:\Scripts directory and you simply type script.ps1 and press ENTER, guess which script will run? You got it: PowerShell won’t run the script in C:\Scripts, but it will run the script found in D:\Archive. That’s because D:\Archive is in your path.
Just something to keep in mind.

How to run scripts without starting Windows PowerShell?
As a security measure you can’t start a PowerShell script by double-clicking a .PS1 file. So apparently that means that you do have to start PowerShell before you can run a PowerShell script. However, that doesn’t mean that you can’t start a PowerShell script from a shortcut or from the Run dialog box; likewise you can run a PowerShell script as a scheduled task. The secret? Instead of calling the script you need to call the PowerShell executable file, and then pass the script path as an argument to PowerShell.exe. For example, in the Run dialog box you might type a command like this:
There are actually three parts to this command:
Powershell.exe, the Windows PowerShell executable.
-noexit, an optional parameter that tells the PowerShell console to remain open after the script finishes. Like I said, this is optional: if you leave it out the script will still run. However, the console window will close the moment the script finishes, meaning we won’t have the chance to view any data that gets displayed to the screen.
Incidentally, the -noexit parameter must immediately follow the call to the PowerShell executable. Otherwise the parameter will be ignored and the window will close anyway.
C:\script.ps1, the path to the script file