I encountered the error when I used below the script on Postgres 13.9 (oracle_fdw 2.4) on Windows 10 64-bit.
CREATE SERVER yf FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver 'yf');
CREATE USER MAPPING FOR postgres SERVER yf OPTIONS (user 'yonker', password 'his');
GRANT USAGE ON FOREIGN SERVER yf TO postgres;
SELECT oracle_diag('yf');
[HV00N]: ERROR: error connecting to Oracle: OCIAttrSet failed to set driver name in session handle
detail：ORA-24315: illegal attribute type
I can connect to oracle server with tnsname 'yf' using sqlplus.
oracle client 10.2.0.4
oracle server 11.2.0.4
The documentation states the requirements:
Oracle client version 11.2 or better is required.
The error is thrown when oracle_fdw tries to set OCI_ATTR_DRIVER_NAME on the session handle, which was not available before Oracle 11. It is no problem to use an older Oracle server version, as long as you are using a less outdated client version.
Related
I'm trying to connect from Oracle Database (dblink) to Postgresql database use Oracle Database Gateway (dg4msql 19), on the Oracle Database Gateway for MS SQL Server all work fine. On the Oracle DB create dblink, but when try to connect get Error message:
ORA-28500 Oracle ODBC SQL Server Wire Protocol driver Socket closed
08S01 Oracle ODBC SQL Server Wire protocol driver
The server does not support SSL {HY000} !
listener work, tnsnames.ora also give correct answer. May be in initdg4msql.ora file I have to use some string to connect without SSL?
HS_FDS_CONNECT_INFO = postgre_servet.net:5432//database - I don`t known that is correct for PostgreSQL, or for PostgreSQL should use only ODBC connection?
How correctly use HS_FDS_CONNECT_INFO = postgre_servet.net:5432//database, or for PostgreSQL should I use only ODBC connection?
The PostgreSQL server is not configured to accept SSL connections.
First, verify that PostgreSQL was built with SSL support: that can be seen from the output of pg_config --configure (should contain --with-openssl).
To configure SSL support, set ssl = on in postgresql.conf and provide a server certificate and private key (parameters ssl_vert_file and ssl_key_file). Reload PostgreSQL to activate.
For details, read the documentation.
I'm trying to setup an easily-replicable (or even manual and I do it once a month or so) process for moving data from a large Azure PostgreSQL database to a more manageable Azure SQL database for end users that are most familiar with SQL Server. I've successfully connected to the PostgreSQL database via PGAdmin, so I know all my connection string info.
I started by installing the latest ODBC driver from here.
I then used a connection string which was given to me from the Azure portal, filled in the proper database name and password, and attempted to use the following drivers:
PostgreSQL ODBC Driver(UNICODE)
PostgreSQL ODBC Driver(ANSI)
I am getting the following error with either of them:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
What step am I missing in this process? Or how best can I troubleshoot this?
After more research, I attempted to add the ODBC driver here:
And got the following error (I'm not sure why Tableau is relevant to this?):
Thank you.
My application server (say 192.168.100.1) and database server (say 192.168.100.2) both are on the same domain. I'm trying to create an ODBC connection from the application server to a SQL Server database on the database server, but at the time of login it generates this error:
Microsoft SQL Server Login
Connection failed:
SQL State: 'HYT00'
SQL Sever Error: 0
[Microsoft][ODBC SQL Server Driver]Login timeout expired
I've checked all configuration for SQL Server and tried possible solutions without resolving this issue.
Important:
A DSN can be successfully created from my own PC but when attempting this server to server as described above, ODBC is facing this problem.
OK, I have got the solution. Sometimes, if SQL Server can't be found on network by its name while creating DSN in windows, the logging in takes time more than usual which tells ODBC manager that Database Server we are looking for is not responding or responding too late.
Solution.
Instead of selecting server from the list while making dsn, use 'server-ip\SQLExpress'.
e.g 192.168.100.2\SQLExpress.
Thats All.
I'm trying to setup a local firebird instance to test against but am unable to connect to it with even ISQL. I have tried to following by following the quick start guide here:
CONNECT ..\examples\empbuild\employee.fdb user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 08001
unavailable database
After some searching I tried modifying that to:
CONNECT "localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb" user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 28000
cannot attach to password database
After confirming I had the right directory path I decided to give on on connecting for now and try creating a new DB:
SQL>CREATE DATABASE 'C:\data\test.fdb' page_size 8192
CON>user 'SYSDBA' password 'masterkey';
Which also gave me the error:
Statement failed, SQLSTATE = 08001
unavailable database
Are there any common pitfalls I might be hitting? I've also tried the commands above both with and without the firebird service running. Also is there a detailed reference on the SQLSTATE codes?
As already mentioned in my comments the problem is caused by running the Firebird server as an application. Firebird has its password database (security2.fdb) in C:\Program Files\Firebird\Firebird_2_5. As this database is (almost, but not entirely) a normal Firebird database, the server requires write access to this database (for the transactions, etc).
By default (with UAC) users do not have write access to the password database, so this requires elevation to Administrator. So access to Firebird requires that you either run the application as a service with sufficient rights (eg as done by the default installer), or when running the server as application to run it 'As administrator'. Another option is to not install it in Program Files.
This BTW applies double when accessing the example employee database as this database file is also located in the Program Files folder.
This is for macOS/OSX (mine is 10.15) firebird ver 2.5 users.
The installation process here does not ask for a sysdba password. Which means: the security database 'security2.fdb' does not exist after a new installation.
This seems to be intentionally for security reasons since > ver 2.5.
To create one, we use the demo database as a helper:
open sql as su: >sudo isql (we don't have user rights on dir)
Connect to a existing db:
sql>connect
"/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
" user 'SYSDBA' password 'masterkey';
Now we created the missing file 'security2.fdb' in the folder:
"/Library/Frameworks/Firebird.framework/Resources/English.lproj/var/"
(jro)
I installed firebird database for the first time in my life (version 1.5.6 on Windows 7), after installation I can not connect to the sample database (employee.fdb exists), or create a database. This gives the following error in ISQL Tool:
C:\Program Files\Firebird\Firebird_1_5\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> CONNECT "C:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb"
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
SQL> create database 'C:\test.fdb'
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
Firebird 1.5 was written (long) before Windows 7, and before things like UAC existed. It may simply be that Firebird 1.5 doesn't work correctly with Windows 7, or that it requires additional effort to work. I'd suggest to install Firebird 2.5.2 (update 1) as that is the latest version and is known to work with Windows 7.
Another problem might be that local system connections don't work as I seem to remember that Firebird 1.5 uses an older local protocol which doesn't work on newer Windows versions. This protocol was replaced in Firebird 2.0. To workaround that you need to include the hostname in the CREATE DATABASE or CONNECT statement, so for example:
create database 'localhost:C:\test.fdb' user 'SYSDBA' password 'masterkey';
Windows 7+ breaks the local api protocol. You have to use Tcpip protocol to connect to the database, even for local connections.