Dblink to Dameng from Oracle got error: [unixODBC][Driver Manager]Can't open lib '/opt/dmdbms/bin/libdodbc.so' : file not found {01000} - oracle

I tried to use a dblink I created in Oracle to access a Dameng database and this error poped up. I tried to isql to Dameng database before, and I could connect to Dameng with isql.
Here is my /etc/odbc.ini:
[dm8]
Driver = DM8 ODBC DRIVER
Description = DM ODBC DSND
SERVER = 10.10.10.73
UID = SYSDBA
PWD = SYSDBA
TCP_PORT = 5236
Here is my /etc/odbcinst.ini file:
[DM8 ODBC DRIVER]
Description = ODBC DRIVER FOR DM8
Driver = /opt/dmdbms/bin/libdodbc.so
threading = 0
I was able to connect to Dameng database via isql successfully.
But when after I set up related Oracle configurations, and connect from Oracle, the error poped up.
Here are some related configurations:
ORACLE_HOME/hs/admin/initdm8.ora:
HS_FDS_CONNECT_INFO = dm8
HS_FDS_TRACE_LEVEL = debug
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so
#HS_FDS_SHAREABLE_NAME = /usr/lib/libodbc.so
HS_FDS_SUPPORT_STATISTICS=FALSE
#HS_LANGUAGE="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
HS_LANGUAGE="AMERICAN_AMERICA.ZHS16GBK"
HS_NLS_NCHAR=UCS2
For ORACLE_HOME/network/admin/listener.ora, I added SID_DESC in existing SID_LIST:
(SID_DESC =
(PROGRAM = dg4odbc)
(ORACLE_HOME = /u01/app/oracle/product/19.0.3/dbhome_1)
(SID_NAME = dm8)
(ENVS="LD_LIBRARY_PATH=/u01/app/oracle/product/19.0.3/dbhome_1/lib:/opt/dmdbms/bin")
)
For ORACLE_HOME/network/admin/tnsnames.ora, added:
dm8 =
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP) (HOST=ylzcs) (PORT=1521)
)
(CONNECT_DATA=
(SID=dm8)
)
(HS=OK)
)
The dblink was created and used in PL/SQL:
drop database link dblink_DM8;
create database link dblink_DM8 connect to "SYSDBA" identified by "SYSDBA" using 'dm8';
select * from v$version#dblink_DM8;
I have searched lots of web pages and encountered many assumptions, but they usually do not match my situation:
Assumption: this libdodbc.so file doesn't exist. Answer: the file does exists at that location.
Assumption: Oracle's install user doesn't have access to this file. Answer: the install user oracle was used to install Dameng database, which is the same user used to install Oracle, so libdodbc.so belongs to oracle.
Assumption: You didn't set up LD_LIBRARY_PATH environment variable. Answer: I did set it up in .bash/profile, and the content of LD_LIBRARY_PATH is :/opt/dmdbms/bin:/opt/dmdbms/bin
Assumption: libdodbc.so has some dependent files missing. Answer: there are no not found entries:
[root#ylzcs log]# ldd /opt/dmdbms/bin/libdodbc.so
linux-vdso.so.1 => (0x00007ffd317fd000)
libdmdpi.so => /opt/dmdbms/bin/libdmdpi.so (0x00007f5852901000)
libdmfldr.so => /opt/dmdbms/bin/libdmfldr.so (0x00007f5851ca1000)
libdmelog.so => /opt/dmdbms/bin/libdmelog.so (0x00007f5851a99000)
libdmutl.so => /opt/dmdbms/bin/libdmutl.so (0x00007f5851884000)
libdmclientlex.so => /opt/dmdbms/bin/libdmclientlex.so (0x00007f585164f000)
libdmos.so => /opt/dmdbms/bin/libdmos.so (0x00007f5851420000)
libdmcvt.so => /opt/dmdbms/bin/libdmcvt.so (0x00007f5850d3f000)
libdmstrt.so => /opt/dmdbms/bin/libdmstrt.so (0x00007f5850b29000)
librt.so.1 => /lib64/librt.so.1 (0x00007f5850915000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f58506f9000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f58504f4000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f58501ed000)
libm.so.6 => /lib64/libm.so.6 (0x00007f584feeb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f584fb1d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f584f907000)
libdmmem.so => /opt/dmdbms/bin/libdmmem.so (0x00007f584f6f5000)
libdmcalc.so => /opt/dmdbms/bin/libdmcalc.so (0x00007f584f474000)
/lib64/ld-linux-x86-64.so.2 (0x0000562c35c01000)
Assumption: libdodbc.so is not compatible with the system. Answer: both the driver and the system are x86_64.
Could there be any other reasons? Any help would be greatly appreciated!

Related

Connection Fail - fails with php 7.3 and 8.0 - tried wamp and xampp - attempting to access a sqlserver database

here is the entire error:
Connection fail
Array ( [0] => Array ( [0] => IM006 [SQLSTATE] => IM006 [1] => 0 [code] => 0 [2] => [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed [message] => [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed ) [1] => Array ( [0] => 01000 [SQLSTATE] => 01000 [1] => 5701 [code] => 5701 [2] => [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed database context to 'sodb'. [message] => [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed database context to 'sodb'. ) [2] => Array ( [0] => 01000 [SQLSTATE] => 01000 [1] => 5703 [code] => 5703 [2] => [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed language setting to us_english. [message] => [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Changed language setting to us_english. ) )
I have successfully installed the following extensions and they show up under phpinfo()
extension=php_sqlsrv_73_ts_x64.dll
extension=php_sqlsrv_73_nts_x64.dll
extension=php_pdo_sqlsrv_73_nts_x64.dll
extension=php_pdo_sqlsrv_73_ts_x64.dll
extension=php_sqlsrv_73_ts_x86.dll
extension=php_sqlsrv_73_nts_x86.dll
extension=php_pdo_sqlsrv_73_nts_x86.dll
extension=php_pdo_sqlsrv_73_ts_x86.dll
extension=php_sqlsrv_80_ts_x64.dll
extension=php_sqlsrv_80_nts_x64.dll
extension=php_pdo_sqlsrv_80_nts_x64.dll
extension=php_pdo_sqlsrv_80_ts_x64.dll
extension=php_sqlsrv_80_ts_x86.dll
extension=php_sqlsrv_80_nts_x86.dll
extension=php_pdo_sqlsrv_80_nts_x86.dll
extension=php_pdo_sqlsrv_80_ts_x86.dll
Here is my php code that is throwing this error:
$serverName = "***********************";
$connectionInfo = array( "Database"=>"*********", "UID"=>"*********", "PWD"=>"*************");
$maxret = 3;
$conn = false;
do {
$conn = sqlsrv_connect($serverName, $connectionInfo);
if($conn !== false) break;
sleep(2);
} while($maxret-- >= 0);
I have installed ODBC related libraries
I'm working on three different machines, with different IP addresses, all enabled on azure firewall (sql database is on azure). On one of the machines it works, two of the machines generates the error above.
Identical php.ini files on two of the machines and in wamp the listed extensions are the same. On one machine the php script runs, on another it generates an error.
The solution to this problem was to install Microsoft SQL Server Management ...
MSMSS

Error: Unsupported DB driver for windows and wamp

I already config my .env file and db.php file for craft with the same information, before i used 'mysql' as driver but i try it as empty and throws the same error.
db.php
<?php
/**
* Database Configuration
*
* All of your system's database connection settings go in here. You can see a
* list of the available settings in vendor/craftcms/cms/src/config/DbConfig.php.
*
* #see craft\config\DbConfig
*/
return [
'driver' => getenv(''),
'server' => getenv('localhost'),
'user' => getenv('root'),
'password' => getenv('****'),
'database' => getenv('craftyblog'),
'schema' => getenv(''),
'tablePrefix' => getenv(''),
'port' => getenv('')
];
.env
# The environment Craft is currently running in ('dev', 'staging', 'production', etc.)
ENVIRONMENT="dev"
# The secure key Craft will use for hashing and encrypting data
SECURITY_KEY="******"
# The database driver that will be used ('mysql' or 'pgsql')
DB_DRIVER=""
# The database server name or IP address (usually this is 'localhost' or '127.0.0.1')
DB_SERVER="localhost"
# The database username to connect with
DB_USER="root"
# The database password to connect with
DB_PASSWORD="****"
# The name of the database to select
DB_DATABASE="craftyblog"
# The database schema that will be used (PostgreSQL only)
DB_SCHEMA=""
# The prefix that should be added to generated table names (only necessary if multiple things are sharing the same database)
DB_TABLE_PREFIX=""
# The port to connect to the database with. Will default to 5432 for PostgreSQL and 3306 for MySQL.
DB_PORT=""
DEFAULT_SITE_URL=""
And i'm using WAMP with this versions:
PHP 7.1.16
Apache 2.4.33
MySQL 5.7.21
I expect solve the problem, thank you.
In your config.php, it appears you're trying to pull in environment variables via getenv(), but you're passing along the actual values you want to use as strings to the getenv() function instead of the environment variable name. The values are set in the .env file so it's more portable for collaborative developers.
In that .env file, there isn't have an environment variable set for the database driver, so you can just pass a string to 'driver' instead in config.php.
If you'd like to pull the values from your .env file, pass the variable names as strings for the environment variables in the expected format for getenv(), like so:
config.php
return [
'driver' => 'mysql',
'server' => getenv('DB_SERVER'),
'user' => getenv('DB_USER'),
'password' => getenv('DB_PASSWORD'),
'database' => getenv('DB_DATABASE'),
'schema' => getenv('DB_SCHEMA'),
'tablePrefix' => getenv('DB_TABLE_PREFIX'),
'port' => getenv('DB_PORT')
];
Your .env file already seems setup for everything, so you should be good to go. However, to use the values from the .env file in the config.php file, you're going to need to pass the variable names as strings. Hope this helps!

Logstash: Error org.postgres.Driver not loaded

I need to get data from a PostgreSQL DB and index it into Elasticsearch.
https://www.elastic.co/blog/logstash-jdbc-input-plugin
When I run /opt/logstash-2.3.3/bin/logstash -v -f es_table.logstash.conf
I receive the following error:
Pipeline aborted due to error
{:exception=>#<LogStash::ConfigurationError: org.postgres.Driver not loaded.
Are you sure you've included the correct jdbc driver in :jdbc_driver_library?>, :backtrace=>["/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-input-jdbc-3.0.2/lib/logstash/plugin_mixins/jdbc.rb:156:in `prepare_jdbc_connection'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-input-jdbc-3.0.2/lib/logstash/plugin_mixins/jdbc.rb:148:in `prepare_jdbc_connection'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-input-jdbc-3.0.2/lib/logstash/inputs/jdbc.rb:167:in `register'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-core-2.3.3-java/lib/logstash/pipeline.rb:330:in `start_inputs'", "org/jruby/RubyArray.java:1613:in `each'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-core-2.3.3-java/lib/logstash/pipeline.rb:329:in `start_inputs'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-core-2.3.3-java/lib/logstash/pipeline.rb:180:in `start_workers'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-core-2.3.3-java/lib/logstash/pipeline.rb:136:in `run'", "/opt/logstash-2.3.3/vendor/bundle/jruby/1.9/gems/logstash-core-2.3.3-java/lib/logstash/agent.rb:473:in `start_pipeline'"], :level=>:error}
Here is a piece of my Logstash configuration:
input {
jdbc {
jdbc_user => 'user'
jdbc_driver_class => 'org.postgresql.Driver'
jdbc_connection_string => 'jdbc:postgresql://1.1.1.1:5432/db'
lowercase_column_names => false
clean_run => false
jdbc_driver_library => '/usr/share/java/postgresql-jdbc4.jar'
jdbc_password => 'pass'
jdbc_validate_connection => true
jdbc_page_size => 1000
jdbc_paging_enabled => true
statement => 'SELECT * FROM "table"'
type => 'table'
}
...
The jdbc4 driver exists. I tried jdbc3 too without success.
ls /usr/share/java | grep postgresql-jdbc
postgresql-jdbc3-9.2.jar
postgresql-jdbc3.jar
postgresql-jdbc4-9.2.jar
postgresql-jdbc4.jar
The Driver class is inside:
jar tf /usr/share/java/postgresql-jdbc4.jar | grep -i driver
org/postgresql/Driver$1.class
org/postgresql/Driver$ConnectThread.class
org/postgresql/Driver.class
org/postgresql/util/PSQLDriverVersion.class
META-INF/services/java.sql.Driver
The port 5432 is open:
telnet 192.168.109.108 5432
Trying 192.168.109.108...
Connected to 192.168.109.108.
Escape character is '^]'.
Authentication to the DB works.
The problem was that I made a mistake in the driver name.
I wrote jdbc_driver_class => 'org.postgres.Driver'
And the correct name is jdbc_driver_class => 'org.postgresql.Driver'
I resolved this issue by following the workaround suggested in this issue
Reason:
This is a known problem that we have with the modules changes in JDK 9 (Jigsaw). The classloaders have seen some changes and a work around we added before to some driver loading is now failing. The jdbc input has the same failing in JDK 11 (9+). We are working on a fix.
Workaround that worked for me:
An "extreme" work around is to copy the driver file to /logstash-core/lib/jars/ directory. These jar get added to the correct JDK classpath as logstash is started via java.

how do you configure unix ODBC on a Linux server

I have downloaded, build and configured
unixODBC-2.3.2.tar
I installed:
oracle-instantclient12.1-odbc-12.1.0.2.0-1.x86_64.rpm
oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm
oracle-instantclient12.1-sqlplus-12.1.0.2.0-1.x86_64.rpm
I configured /usr/local/etc/odbcinst.ini as follows:
[Oracle]
Description = Oracle ODBC Connection
Driver = /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
Setup =
FileUsage =
libsqora.so.12.1 file exists:
file /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
/usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
I also configured the odbc.ini file:
[prd_db]
Driver=Oracle
Description=prod database
Trace=Yes
ServerName=//prddb01:1521/dbp01_svc1
When I use prd_db credentilas to connect using isql:
isql prd_db
I get connection error. User name and password are accurate and I can connect using sql developer.
what am I missing? I need to configure odbc connection in a linux server.
ldd /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
linux-vdso.so.1 => (0x00007fffd918b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f6c73bb2000)
libm.so.6 => /lib64/libm.so.6 (0x00007f6c73939000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6c7371b000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f6c73503000)
librt.so.1 => /lib64/librt.so.1 (0x00007f6c732fa000)
libclntsh.so.12.1 => not found
libodbcinst.so.2 => /usr/local/lib/libodbcinst.so.2 (0x00007f6c730e8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6c72d6c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6c74242000)
libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6c72b61000)

LazReport doesn't work on second machine

I have two computers - Ubuntu 12.04 + Lazarus. Let's call them A and B.
I develop a program on A. It works fine.
I run the same program on B using Lazarus and it works fine.
Then I make a compiled program (binary) on A and try it on B. Now the problem starts.
Everything works fine except that none of the reports (LazReport) appear. There's no error. Just no response. The program continues without a crash but just no response. How is this possible?
Clues:
On machine A and B, I installed the software (Lazarus) as the default admin user.
On machine B, I have another user account but this is a standard user.
On machine B, I installed LazReport component on Lazarus using the standard user account. So I suspect a permissions issue.
Then I removed the LazReport component on Lazarus from machine B and reinstalled it a second time. But this time I ran it as admin like this gksu -u ADMIN -w startlazarus but still no change.
Please advice how I may solve this problem.
My restriction:
I must be able to do this using the standard account and not ADMIN. Is this even possible?
Thanks!
EDIT: here's the output of ldd:
linux-gate.so.1 => (0xb76f3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76c3000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb758f000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb756d000)
libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xb7105000)
libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 (0xb7056000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb7007000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6f0e000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb6f0a000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb6f05000)
libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 (0xb6ebb000)
libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xb6df0000)
libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb6dd0000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6dca000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6c20000)
/lib/ld-linux.so.2 (0xb76f4000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6bff000)
libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6aa8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6a7c000)
libpangocairo-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb6a6e000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6a68000)
libpangoft2-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6a3c000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6a08000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb69f6000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb69eb000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xb69e7000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb69d7000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb69ce000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb69c3000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xb69be000)
libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb69ba000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb69b3000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6977000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb696e000)
libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb68d5000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb683b000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6811000)
libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xb680d000)
libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xb6803000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb67ec000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb67e8000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb67e1000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb67c2000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb67aa000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb677f000)
They appear IDENTICAL on machines A and B except that the hex number within brackets is different. Apart from that, it's the same line to line.
EDIT: More info - new findings...
I opened a terminal. Then ran Nautilus. Then I run my binary and when trying the report, I got this error in the terminal:
[WARNING] SetAlphaBlend called without handle for
frProgressForm(TfrProgressForm)
I have no clue but I believe this is the bug. I have no form like the one mentioned either.
Apparently, as I discovered much later, the reports didn't work outside of the development folder although the rest of the application did.
The solution was to simply copy the report files (.lrf) and put it into the destination folder that contained the binary.

Resources