I'm currently accessing an Oracle database version 9i (9.2.0.8.0) using perl modules DBI (1.613) and DBD::Oracle (1.26). The current scope of the project now requires that I access a version 8i (8.1.7.4.0 ) Oracle database and, according to the DBD::Oracle project, I can only access this second database with a DBD::Oracle version 1.20 or below.
I know I could possibly use the DBD version 1.20 to access both databases, but I was wondering if its possible to have installed the two versions of the DBD module and use the acceptable version for each database (less prone to errors).
I don't believe that the server version has any bearing on the DBD::Oracle version you can use, only the version of the client libraries that you install. The 9.2, 10.1, and 10.2 versions of the Oracle client libraries support connecting to Oracle server 8.1.7.4, and the latest version of DBD::Oracle remains compatible with all client libraries from 9.2 up, so I don't think that you will actually have any problem at all. However, if you install the version 11 client, you will lose the ability to connect to server versions below 9.2.0.
Install the different versions of DBI/DBD::Oracle into two different places, see INSTALL_BASE/--install_base. Access them seperately by setting PERL5LIB appropriately.
local::lib helps you automate this whole affair.
If you want to access the two database versions from the same program run you can do as follows:
install both versions in your system using local::lib
run a DBD::Proxy server with #LIB configured to load one version of DBD::Oracle
run your script with #LIB configured to load the other version of DBD::Oracle
in your script connect to one database using DBD::Oracle as usual and to the other one through the proxy.
Related
Running a Laravel installation on a RedHat Enterprise Linux 7 server using PHP 7.1. I can see php-pgsql.x86_64 listed in the available yum packages, but it doesn't appear to be compatible with PHP 7.1 (and indeed is listed as version 5.4.16-43.el7_4.1).
On a lark, I tried installing it anyway and physically moved the pgsql.ini and pdo_pgsql.ini files from /etc/php.d into the relevant PHP 7.1 folder /etc/opt/rh/rh-php71/php.d/ (and did the same with the .so files they reference), but that returns an error indicating that the package couldn't be read (undefined symbol: file_globals_id in Unknown on line 0).
Has anyone managed to get PHP 7.1 talking to PostgreSQL on RHEL 7?
The sysadmin who originally created the server for me set me straight. The problem was I was looking in the wrong repository for the packages I needed for my particular PHP installation. Running the following two commands did the trick:
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-odbc
sudo yum install --disablerepo=* --enablerepo=rhui-REGION-rhel-server-rhscl rh-php71-php-pgsql
We then added those two packages to the Ansible playbook so future generations would not suffer needlessly.
Would AIX 7 support Capistrano v3.4.0 (or above) and its dependent scripting tools such as Gem, Ruby, Rake, etc...? and if it does, where could one find a list of supported versions for the dependent scripting tools?
As stated in the Capistrano README, you need Ruby 2.0 or higher. All of Capistrano's gem dependencies are automatically installed when you run gem install capistrano, assuming that your Ruby 2.0 environment is working.
That said, installing Ruby on AIX seems challenging. You may have to compile it from source: Installing Ruby on AIX .
This assumes of course that you want to deploy from AIX (i.e. run the cap command on an AIX machine) as opposed to deploying to AIX (using a Mac, PC, or Linux machine to deploy to an AIX server). If you want to do the latter, you should be fine: Capistrano has no requirements for the server other than sshd.
I need to upgrade PostgreSQL that comes with Chef Server.
/opt/opscode/embedded/postgresql/9.2
It's been installed from binaries, not apt, and the installation directory path suggests that it's an embedded version. Although I'm able to access it remotely just fine.
Has anyone tried patching the built-in PostgreSQL that comes with Chef?
My target version is 9.5 as I need support of json functions available in 9.5.
When trying to get local data to Heroku, I am encountering a version mismatch between two different versions of pg_dump.
Specifically, I am getting this message:
pg_dump: server version: 9.2.2; pg_dump version: 9.1.4
pg_dump: aborting because of server version mismatch
I have found others with this problem, but do not know enough to implement the proposed solutions. (I am new to Ruby on Rails, PostgreSQL, Heroku, and the Mac! Very much at the stage of playing around the picking things up as I go.)
I was thinking I might simplify my life if I uninstalled all PostgreSQL on my local machine and started again with a clean install of PostgreSQL 9.2.2 from http://postgresapp.com/, but I don't know how to go about doing the uninstall.
I'm running Mac OS X Mountain Lion 10.8.2.
OS X 10.8 comes with pg_dump version 9.1.4 in the /usr/bin directory, along with psql and other programs that are client-side PostgreSQL tools. It does not mean that PostgreSQL as a server is installed (unless you have OS X Server Edition).
So you don't have to uninstall PostgreSQL because it's not installed and it's better not to remove these postgres client tools in /usr/bin because they belong to the system as shipped by Apple. They just need to be side-stepped.
The package provided by postgres.app comprises both the PostgreSQL server and the client-side tools of the same version as this server. These tools get installed in /Applications/Postgres.app/Contents/MacOS/bin
To use these instead of the 9.1 ones from Apple when you work in a Terminal, postgres.app documentation says to do:
PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
and put it in your .profile file.
Once you have done that and you run pg_dump, you should no longer get the error that's it's the wrong version, because it would be the one that ships with postgres.app (currently 9.2.2).
I have this setup and it works OK for me.
If you only need to upgrade your pg_dump to the latest version and you have homebrew and mac, if the app has the latest version and your local pg doesn't:
brew upgrade postgresql
If you're using postgresapp 9.3.x, the path is different. The following worked for me (courtesy of http://sigmyers.com/blog/2013/3/12/postgres-pgdump-version-mismatch-error-postgresapp-postgresappcom)
export PG_BIN_PATH="/Applications/Postgres.app/Contents/Versions/9.3/bin/"
PATH=$PG_BIN_PATH:$PATH
Check here for the latest path: http://postgresapp.com/documentation/cli-tools.html
I'm running Mountain Lion Server. My PostgeSQL server is at version 9.2.1 and the default tools are at 9.1.5.
I had to use:
PATH="/Applications/Server.app/Contents/ServerRoot/usr/bin:$PATH"
to make it work.
Yep, sometimes if you run Postgres.app this may happen after upgrade. Make sure you restart your Postgres.app - it will update your PATH.
In my case I have postgresql installed via homebrew and the executables are here: /usr/local/opt/postgresql#9.6/bin
Or you copy the dump and restore executions to the /Applications/Postgres.app/Contents/SharedSupport folder
or in PdAgmin you point the PG bin Path (in properties -> binary Path) to the path of the executables of your postgre
I want to upgrade database postgresql from version 8.3 to 9.0 on Jira application.
Which RPM should be used to work with Suse SLES10.3 64bit?
How to install Postgresql 9.0 in parallel to Postgresql 8.1?
The best bet to find packages for SUSE distributions is the openSUSE Build Service. The direct links there are a bit of a pain, so please look for yourself.
Parallel installation of multiple major PostgreSQL versions is not yet possible using SUSE RPMs. If you need to do that, you will probably need to build from source.