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.
Related
I am migrating a MS Access back end data file to SQL Server. All data has successfully transferred, and it viewable in SSMS, however, if I open the linked table in the Access front end, all currency field entries that are greater than 0 are blank.
If I run a query that filters currency columns based on their value, I get the correct number of records returned, but still the fields show as blank.
This makes no sense to me, please help.
I would try linking the table using sql driver (this is a long time legacy driver). It been pre-installed on computers since windows XP.
If that does not work, then try linking using the native 11 (or later driver). These drivers are preferred, but they are not installed on each workstation and thus deployment can be a hassle.
And to prevent the need to configure each workstation? Always (but always) use a FILE dsn. This is suggested because Access will convert the connection automatic to DSN-less. This means that you not have to setup a DSN on each workstation (but you STILL require the native driver 11-17 having been installed on each workstation, and that driver will have to match what you linked with.
If EITHER of the above STILL does not display the money type columns?
Then this is a regional setting. (the regional setting of the sql server is not matching what your regional settings are on the client workstation.
So, then create a new DSN (as noted always FILE).
And during the re-link process try selecting the regional settings:
So, you should not have to change the "money" type to decimal. And doing so could introduce all kinds of issues.
So, try the above first. Both the legacy (windows built in) "sql driver", and the natve 11-17 drivers work for me WITHOUT having to select the above regional settings, but if both sql legacy and the newer native 11 (or later) drivers don't work, then try re-linking again and selecting the above option.
NOTE ALSO that you do NOT get the above panel during a re-link, nor do you get the above panel during a re-fresh. Nor do you get the above panel if you select a existing DSN. You MUST create a new DSN to get/see/use the above panel. It ONLY appears one time, and ONLY during the time you create a new DSN - not during re-use or a re-link or a re-select of a existing DSN.
Wow, this takes me back.
Assuming you're using an ODBC DSN to set the connection for the linked tables, set the ODBC data source to use the "SQL Server Native Client" driver, not the "SQL Server" driver. As I recall you can't change the driver for a DSN, so you'll have to remove your existing one and create a new one.
To get there:
Open start menu > type "odbc data sources" > click to open odbc data sources > click add > scroll all the way to the bottom of the drivers list and choose SQL Server Native Client as the driver > set up the rest of the DSN according to your environment.
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>
Is there a way for a normal user (client-side) without elevated privileges (no special database permissions, local administrator, or any of the sort) on the server to get any kind of unique ID from a server (MAC address, database installation ID, server hardware ID) or anything of the kind?
Basically I am looking for an ID to verify the installation. I know I can do it by writing some sort of ID into registry and the database to install server-side, but is there a way to do it without installing anything? The minimum requirements for that is that I get that from MySQL and SQL Server with Linux and Windows.
My current research suggests that there is no such thing. As seen in the comment below:
I think any answer is going to require xp_cmdshell since unique
hardware information is not exposed directly to SQL Server
I dont think you can get hardware details directly from Sql-Server . it may possible throw the other programs which can contribute with both sql-server and your system hardware .
there is a pre-define function in sql server which will give you unique and random id .
create table TableName
(
id varchar(max) default newid()
)
Best I can find is that you can use file_guid from sys.database_files. You only need to be in the public role to do that and that should be unique per DB. If you create or remove database files, you'll run into trouble, and it doesn't do anything about verifying that you're on the same server.
Note that if your DB was created prior to SQL Server 2005, this value will be null since it didn't exist.
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 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!