This statement returns null instead of 64 random bytes:
select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
What is causing it to return null? Database is Oracle 10.1.0.2.0 running on Windows Server 2003 and I want to use the random bytes as salt for password hashing.
Edit: Here's the output from sqlplus:
Connected to:
Oracle Database 10g Release 10.1.0.2.0 - Production
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
SQL>
Edit2: When switching to Oracle 11 the query works. I have no idea why it doesn't work on Oracle 10 but have decided to not use that old database.
It works perfectly. I have tested it on Oracle 12c.
Update
I have checked My Oracle Support(Metalink), however, did not find anything related to this function returning NULL. Certainly, not a bug.
Anyway, looking deeper into the function and it's usage in the documentation, I came across SQLNET.CRYPTO_SEED
SQLNET.CRYPTO_SEED
Purpose
Use the parameter SQLNET.CRYPTO_SEED to specify the characters used
when generating cryptographic keys. The more random the characters
are, the stronger the keys are. The string should be 10-70 random
characters. This optional parameter is required for when encryption or
checksumming are turned on. Encryption is turned on if the
SQLNET.ENCRYPTION_CLIENT parameter is specified for the client and the
SQLNET.ENCRYPTION_SERVER parameter is specified for the database
server; checksumming is turned on if the SQLNET.CRYPTO_CHECKSUM_CLIENT
parameter is specified for the client and the
SQLNET.CRYPTO_CHECKSUM_SERVER parameter is specified for the database
server.
It might be possible that the parameter is not properly set in your environment. I don't have 10g version(obsolete though) to test.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing option
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
427AECD44D27CDF6CDC8F290D9F8079109BAB8AECD7E687E7ADF8E15825BBDF3D746FBC181059443
965B1425B224CC46E8CD07CC2D02B2E023238E8883520A19
SQL>
Related
I'm trying to set a connection between a PostgreSql 12 64bit on a Windows 10 (64 bit) with a MS Access 2013 (64 bit) on a windows 8.1 64bit using some of the fdw's. At this regard I:
- Set a System DSN with MSAccess 64bit driver (msdata) Unfortunately MS removed the test option for
access database connection but it seams to work.
- Using ogr_fwd I was able to set the Foreign Data Wrapper but when setting the Foreign server it refused the following options:
[dsn:msdata] (dsn not valid option),
[datasource:'Z:/database.accdb', format:'MDB'] (Unable to find MDB format idem using 'OCDB' as
format),
[datasource: 'msdata'] or [datasource:'OCDB:msdata] (unable to connect to data source xxxx)
Finally y gave up using ogr_fwd but I was able to connect to a MySQL database using it with a MySql
64 bit driver.
I tried ocdb_fdw with some more luck. Was able to create the Foreign Server; the User Mappings and two foreign tables but when I tried to run a simple query on a three records table it took for ever without showing a result ´- I tried to set the option "use_remote_estimate" on the foreign tables with the same results.
I set it up as follows:
CREATE FOREIGN DATA WRAPPER odbc_wrapper
VALIDATOR public.odbc_fdw_validator
HANDLER public.odbc_fwd_handler;
CREATE FOREIGN SERVER odbc_server
FOREIGN DATA WRAPPER odbc_wrapper
OPTIONS(dsn 'msdata');
CREATE USER MAPPING FOR PUBLIC (Ms Access database not password protected)
SERVER odbc_server;
CREATE FOREIGN TABLE public.sex
id integer NOT NULL,
sex character varying(20)[] NOT NULL
SERVER obdc_server
OPTIONS (use_remote_estimate 'True'); -- run with and without this option --
As mentioned above, the odbc_fdw allows to set it up, but I was unable of getting any return data from it.
Linking a table from Ms Access using the Ms Access MSConnector works just fine but unfortunately it only allows to link on existing PostgreSQL tables which it's not what I need. I think that somehow this
is related to the 32/64 bit mess of the Ms Access driver, but I couldn't find a workaround.
Any help would be most appreciated.
EDIT: After struggling for some time, i found out a problem with my MS Driver not related to odbc_fdw or to PostgreSQL but to windows itself. Once I fixed it, the driver ( and the DSN system data source) works just fine when tested using pyodbc.
This solve the issue of freezing (or running for a long time) but when running a query on the foreign table I got another issue that was an "ERROR: Connecting to driver SQL state: 58000 - Which stands for error outside PostgreSQL.
I tried several options at the Foreign Table such as odbc_DATABASE databasename;
schema databasename; odbc_table tablename with the same result.
I still don't have idea why ogr_fdw doesn't recognize the MsAccess 64bit driver.
I have created an Oracle heterogenous service to db2 using DG4ODBC.
try login using isql and select using this query
select *from workorder#maximo
I get a result set all of the data
but when I am login using sqlplus Oracle I get this error
this is my heterogenous init
and I try using HS_FDS_TRACE_LEVEL=DEBUG and get some column have a sql_null_value
This the sample of the log from debugging:
if any columns have null value then the data cannot be showing.
how I can show the data even though have a null value??
I am using Oracle 12c and db2 10.5
Try using:
HS_FDS_SQLLEN_INTERPRETATION = 32
(From Ocacle docs) This parameter is only valid for 64 bit platforms. ODBC standard specifies SQLLEN (of internal ODBC construct) being 64 bit on 64 bit platforms, but some ODBC driver managers and drivers violate this convention, and implement it as 32 bit. In order for the gateway to compensate their behavior, you need to specify HS_FDS_SQLLEN_INTERPRETATION=32 if you use these types of driver managers and driver.
It is unclear from your question the bitness of the Db2 odbc client, or whether the driver-manager or driver is using 32-bit or 64-bit internally for this. After changing this parameter you may need to re-initialise. A CLI trace of Db2 (google for instructions) may also expose this.
I've got this error when I was trying to load a TEXT data type from Postgres to Oracle VARCHAR2(4000) and the source data in the TEXT column was bigger than 4000 bytes.
One of available workarounds could be to map TEXT column to PL/SQL's VARCHAR2(32767) variable or maybe LONG, CLOB data type.
I have a big deal: I have to connect (I just want to read data, not to write) to my customer's IBM AS/400 (aka iSeries, now IBM i) server...
I think I have all parameters needed (given me by the AS/400 programmer), but I can't figure out which driver I have to use, and if I have all software needed to to this!
I've installed IBM AS/400 ClientAccess 5.8 driver (with a patch for latest OS), and now I'm trying to configure a new Linked Server in my Sql Server 2008 R2 (x64) server.
First problem: Which driver should I use?
I have so many choices (but maybe none of these works!!):
IBM DB2 UDB for iSeries IBMDASQL OLE DB Provider
IBM DB2 UDB for iSeries IBMDA400 OLE DB Provider
IBM DB2 UDB for iSeries IBMDARLA OLE DB Provider
...or maybe other generic OLEDB/ODBC drivers?!
Second problem: Where should I put my parameters (in which fields I mean!)
In any case, in I choose a provider for my Linked Server, obviously I have to set my parameters...but I only have this:
Username of an ADMIN user
Password of the ADMIN user
AS/400 server IP address
The name of "main" archive, in which my data are stored (something like ACG_DATV2)
Third problem: How should I write my queries? How to reference an AS/400 "archive" and tables?
I don't know how to build my reading query: where are tables and views (?!) stored and how can I reference them?
Thank you in advance!
I think there are many ways to achieve what you want, but I'll try to explain what I would do in your case.
With that version of IBM ClientAccess (and also the patch), I should not have troubles in getting connected with a Sql Server 2008 R2 Linked Server if you use the correct data provider.
First of all, try to configure your linked server in this way:
Linked server name: what you want, it's just a custom name (example: MYAS400)
Provider: IBM DB2 UDB for iSeries IBMDASQL OLE DB Provider
Product name: not important, something like iSeries Access OLEDB Driver
Data source: AS/400 server IP address (example: 192.168.0.1)
Either if you configure the Linked Server using the wizard or by SQL code, the first time it will need to access the data of the AS/400 server, you'll be asked for credentials, with a typical iSeries window (look at my example).
Set your username (User ID) and the relative password, without regarding the case of the strings!!
As a general tip (but this is only related to my experience!), try to avoid special characters and upper/lower cases distinctions...
If you arrive here (no problems in the Linked Server creation), the Linked Server should work (so the first and the second problem are solved): let's build the first query!
Once the Linked Server is created, all you need is just to correctly reference the archive, the library and, of course, the correct table and the Linked Server (by name): with this informations, build a query like this (it's the usual T-SQL syntax):
SELECT
(Field1)
, (Field2)
, *
FROM (Linked Server Name).(Catalog Name).(Library).(TableName)
The only information you're probably missing is the "archive": you can easily find it browsing the Catalogs tree inside your new Linked Server, or just use iSeries Access Navigator tool!
So, in your case, I think the query should be (more or less):
SELECT
FILIO
, DTVLD
, DTVLA
, SEQZA
, CFIMP
, PADRE
, TPVLD
, CMVLD
, *
FROM MYAS400.S242DA0A.ACG_DATV2.ANLE200F
Note that S242DA0A is valid only in my case...
Remember also that:
AS/400 will probably ask you for credentials very often: also if you close and reopen SSMS.
Performance?...better to talk of something else :) ... extract the tables in your Sql Server tables and query them from there! Do it with a simple: SELECT (Fields) INTO myTable FROM (AS/400 table)
I've tried this process many times, I didn't have many troubles (once I get skilled about!)...but only for reading data (as you asked)! Never tried to update data!!!
GOOD LUCK!
I just can't connect to Firebird on Ubuntu.
Through the terminal I do:
rafaeljesus#ubuntu:/tmp$ isql-fb
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect .my_database.gdb user sysdba password masterkey;
Statement failed, SQLSTATE = -922
file /tmp/cnes.gdb is not a valid database
Searching on the web I realized that this occurs when the file is corrupted, which is not the case ... I do not know if this is because the file is in gdb. instead of fdb..I do not know about Firebird ...
I really need some help.
As you don't specify any version information, ODS version of the database, if you upgraded the Firebird version, or whether this database was moved from another system etc I provide some options:
The database was created on a 32 bit platform and now moved to a 64 bit platform without backup/restore: older file structures of Firebird (at least ODS 10 from Firebird 1.0 and InterBase 6) are specific to the bitness of the platform: a backup on the 32 bit platform and a restore on the 64 bit platform should suffice
The database was created on a big-endian platform and now moved to a little-endian platform without backup/restore
NOTE: In both cases make sure you create a transportable backup (it is the default, but check).
Another option could be that a restore of the database failed before the full database was restored. Check your restore log and address any errors (see Firebird 2.5 reports "is not a valid database" although it is for a suggestion )
If all else fail: contact a Firebird/Interbase recovery/repair company like IB Surgeon.
I have created a linked-server definition according to the article at :
http://www.ideaexcursion.com/2009/01/05/connecting-to-oracle-from-sql-server/
My aim is to transfer rows to tables at Oracle 11gR2.
After creating linked server, whenever I try to select a table using a query like :
SELECT *
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I get the error below :
Msg 7356, Level 16, State 1, Line 1
The OLE DB provider "OraOLEDB.Oracle" for linked server "192.168.1.188"
supplied inconsistent metadata for a column. The column "EVENT_OBJECT"
(compile-time ordinal 2) of object ""ESIPARIS"."T_ERROR_LOG"" was reported
to have a "LENGTH" of 50 at compile time and 100 at run time.
One more thing is that it duplicates field names whenever a select statment is prepared by "Sql Server Management Studio", some fields are duplicated as below :
SELECT [EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[EVENT_ID]
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I would be very happy to hear from you about any ideas, thank you for your concern,
Best Regards,
Kayhan YÜKSEL
There are a number of scenarios which might throw this error:
your distributed query in SQL Server references a view with an underlying table in Oracle with a primary key column created in a certain way, Find out more
there's a bug when the querying a view with numeric columns. Find out more
it may be a problem with driver incompatibility, such as using the MS OleDB driver instead of the one Oracle provides.
If it isn't the driver one possible workaround is to use OPENQUERY. Otherwise. this support note contains general information on troubleshooting linked server and Oracle.
(This problem is a fairly generic one, so it turned out that the actual resolution was none of the things I suggested. I'm incorporating #kayhanyüksel's solution in the body of this response for the sake of completeness.)
Solved it with changes at listener and tnsnames. We are now able to connect from SQL Server to Oracle 11gR2 (running on 64 bit Red Hat Enterprise Linux 5.4 ) and vice versa. Documents followed are
- Making a Connection from Oracle to SQL Server
- The Oracle Gateways documentation
I had the same problem: The column ...... was reported
to have a "LENGTH" of 50 at compile time and 100 at run time. and duplicate column names when selected.
while i was trying to run a query in MS SQL from an ORACLE 11g database
I used the follownig type of query and it worked !
DECLARE #TSQL varchar(8000)
SELECT #TSQL = 'SELECT * FROM OPENQUERY(MyLinkedServer,''SELECT * FROM TableName'')'
EXEC (#TSQL)
where MyLinkedServer is the name of the linked server and
TableName is the name of the table.
here you have the link to the article that helped me: http://support.microsoft.com/kb/314520
Old thread but it may be useful to someone.
When I recently encountered this error, using as provider the MS OleDB driver instead of the Oracle OleDB provider solved the problem.
I have the same issue with 11g client but it was disappeared with client version 12 which works for me is using OPENQUERY and to_char with the field that makes problem.
I confirm that SQL management studio (no matter what version) gives many duplicated field. The only installing of last driver version we can have consistent queries. I hope it can be useful for you!