I'm working with Postgres from SSIS thru ODBC Unicode driver ver 13.01. 32-bit connection.
I can successfully connect to all Postgres tables but can not able to see any view thru that connection.
How can I access to Postgres views from SSIS?
I just tried using the SQL Server import wizard (which uses a subset of SSIS) and I also could not see any views in the list of "Tables and views" for my PostgreSQL database
but when I chose the "Write a query to specify the data to transfer" and entered
SELECT * FROM view1
for the "SQL statement" it allowed be to import the view data into a SQL Server table.
I had a similar problem because the view belonged to another user and the search context in postgres was not set for my ssis-login user.
Regards
Related
I am trying to run this query from an instance on premise to the Master database in Azure.
I can query the other database on the Azure instance with my linked server so that is working and the query I'm trying to run, runs when I log onto the Azure instance.
I just cannot get it to run from my server that has a linked server object set up for Azure.
The code I have tried is:
SELECT [database_id],[name],[Compatibility_level],[collation_name],[state_desc]
,[recovery_model_Desc],[is_broker_enabled],[is_cdc_enabled]
FROM [LinkedServerName].[Master].[sys].[databases]
I have also tried it this way:
EXEC ( 'SELECT [database_id],[name],[Compatibility_level],[collation_name],[state_desc] ,[recovery_model_Desc],[is_broker_enabled],[is_cdc_enabled]
FROM [Master].[sys].[databases]') AT [LinkedServerName]
Again with no success. I am getting this error:
Msg 40515, Level 16, State 2, Line 9
Reference to database and/or server name in 'Master.sys.sp_tables_info_90_rowset_64' is not supported in this version of SQL Server.
Any ideas to help me get around this?
When you created the linked server you specified the user database as the “Catalog” database, you did not specified the master database as the catalog (the database used for the linked server). That is the reason you are using cross database queries, and cross database queries using three and four-part names are not supported on Azure SQL Database as explained here.
Additionally not all sys tables are supported on Azure SQL Database. You will find some DMVs available on Azure SQL Database that do not exist on SQL Server on-premises and vice versa.
I need to be able to connect to 3 remote databases simultaneously from my local SQL Server instance using SQL Server 2008 R2. Db1 and Db2 are both on Svr1 and Db3 is on Svr3. Each database requires a different login to gain access. I want to write a script that has simultaneous access to all 3 databases.
I gave up trying to create these using sp_addlinked server (despite successful use of this in past projects) because I simply could not get any of the connections working. I did manage to set up working linked servers for access to Db1 and Db3 on Svr1 and Svr3 respectively, no problem, using SSMS (right click on Linked Servers, New Linked Server). However, I don't know how to set up the linked server for db2 - it will not allow me to set up 2 linked servers with the same name (understandably). When I try to set up one using a name that does not map to a known SQL Server instance (and so use a data source or provider string to connect), it won't work.
Can I do what I want to do using the SSMS method? Or is there a way I can use the same linked server for Db1 and Db2 but use different logins somehow?
I have data in an Azure SQL database, which I would like to pull into an Excel sheet through the use of stored procedure(s) which require parameters.
However, I'm struggling to do this, as I cannot get it to work how it works with a local SQL server. Ordinarily this is done through Microsoft Query, defining the connection to the database, and entering { CALL sproc (?) } and then using the Connections command to map a cell to the parameter.
I cannot set up a connection to the database in MS Query. When I enter the xxx.database.windows.net as the server, my username / password, and then try to switch to database I need to use I get the message below
Filling listbox failed:
SQLState: '37000'
SQL Server Error: 40511
[Microsoft][ODBC SQL Server Driver][SQL Server]Built-in function 'has_dbaccess' is not supported in this version of SQL Server.
Can anyone offer any assistance please?
Create a text file with the .DSN extension then add content like the following into it...
[ODBC]
DRIVER=SQL Server
SERVER=xxxxxxxx.database.windows.net,1234
APP=Microsoft Office 2010
WSID=NA
DATABASE=DB12345
[Microsoft Office]
UID=myUsername
PWD=myPassword
You can then just use this connection from Microsoft Query without dealing with the dialogs that are giving you grief.
I just figured this out with a combination of Youtube videos and dumb luck lol. You have to create an OBDC connection with Microsoft ODBC Driver 13.1 for SQL Server (or higher.) Make sure you connect and define the correct database in the ODBC object while entering in your Azure SQL connection info. Once that's done from within excel you can use MS Query to select that ODBC object and pull the data as you normally would.
I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok
I'd like to connect an existing SQL Server EXPRESS datatable (wich I'm using in WebDeveloper 2010) to an Access 2007 database, but I haven't retrieving my datatables.
I'm doing this sequence:
In "external data" ribbon, selecting ODBC datasources
Linking to datasource using a linked datatable
Creating a new .dsn file SQL Server driver
In SQL server field, informing .\SQLEXPRESS
In autentication, selecting NT autentication using network logon
In this step, I supose that the system would show me my database, or a way to inform its path. But I'm not achieving to inform database path, neither selecting my tables. In "change standard database to..." I have only the options: "master", "model", "msdb" and "tempdb". When I try to inform my database path in "Attach database file name", there's an exception "Invalid database". I don't know what should I doing wrong, or how can I solve this issue.
I've been reading about several problems on linking SQL server databases to Access, but to this problem I haven't found a solution, which should be easy. Thanks for helping.
When you create ODBC connection, check whether you can set default database as the database that you are looking for. If no, then the problem lies some where in the ODBC and you can fix that first and then try to like the table.
If you can set the default database in the ODBC Connection, then then problem is likely to be in MS-Access.
Hope this will help you to identify the problem.
Please update the status.
I believe, MS-Access expects timestamp column in the Sql Server table, if you need to update the data.