My 2 server both use SQL Server 2008 R2
I have my local SQL server and also an Amazon machine running an instance of SQL-Server there.
I'm able to connect from my local machine to that Amazon SQL using the standard 10.10.10.10, 1433 connection from my local Management Studio.
What i need to do now is to run a query that says ..tells me what records I have locally that are not on the Amazon server right now.
Something like:
SELECT *
FROM [LOCAL].dbo.Table1
WHERE Field1 NOT IN
(SELECT Field1 FROM [AMAZON].Database1.dbo.Table1)
================================
Question:
I don't know how to write the "AMAZON" location on the Query window itself, since it's running on a different server.
Any help is truly appreciated !!!
You have to configure AMAZON Server as LINKED Server on your local machine. If you name it "AMAZON" - you query will work exactly as you wrote.
In SSMS, \Server Objects\Linked Servers. Right click, 'new linked server'. Name your server, and choose 'SQL server' radio button. Because I was authorized user on both machines with windows credentials, I selected 'Be made using the login's current security context' radio button under the security tab, and did not even have to fool with the local/remote user mappings.
In order to be able to run queries across multiples servers, a link (linked Server) must be established between the 2 Servers. To create a linked server,
Navigate to the Linked Server Sub-folder under the Server Object folders
Right Click on the Linked Server Folder
Click on New Linked Server
Supply the Connection Strings for the Server
Name your Linked Server.
You can now use the full object qualification (LinkedServer.Database.tableOwner.Table) to access the objects.
Good Luck !
You should open your registered server window and create a group for your servers. then you right click the group name and select new query (Or select several servers in that group). if you execute the query it will rung against the servers selected.
Related
Reading through the documentation of Tableau Server I was not able to determine if the following works:
I have set-up Tableau Server 2020.4.0 along with the PostgreSQL
driver
I added a connection to an internal, i.e. non-public, PostgreSQL DB via Tableau Server
I can access the PostgreSQL via logging in to Tableau Server just fine
I am also able to connect to the Tableau Server through Tableau Desktop BUT I cannot connect to the PostgreSQL as it is not directly accessible from the client machine running Tableau Desktop.
Is there a way to access this non-public PostgreSQL database connected to Tableau Server from Tableau Desktop through Tableau Server?
If the server is accessible via SSH then you can set up a port forwarding tunnel.
ssh -L 127.0.0.1:5432:postgres.example.com:5432 tableau.example.com
Then in the datasource within Tableau Desktop change the host to 127.0.0.1 from postgres.example.com. If there are SSL errors you may want to add an entry to your /etc/hosts file and not change the hostname.
sudo echo '127.0.0.1 postgres.example.com' >> /etc/hosts
Answering my own question and following #matt_black's comment it is indeed possible to access and use published Datasources from Tableau Desktop which are not directly accessible.
For that you need to login to the Tableau-Server UI (not TSM via 8850), create a Workbook, click on "Datasource" (bottom left hand corner) add a single or multiple connections and then head back to any "Sheet" Tab (also bottom left hand corner).
At this point it is recommended to save the Workbook as "Template", i.e. "my_published_datasoure_template" – explanation follows.
After saving the Workbook you need to hover over the Datasource-Icon in the "Data" Tab and click on the appearing dropdown-arrow to publish the Datasource.
It needs to be mentioned, that once a Datasources has been published this way it asks you to update the workbook right afterwards which you must deny in order to be able to edit the Datasources of the workbook afterwards.
If you need to edit the Datasource at a later point be sure to delete the previously published Datasource then edit and re-publish it.
When I am trying to process dimensions after creating a data source view I get the error:
The project could not be deployed to the server because of the following connectivity problems : A connection cannot be made. Ensure that the server is running. To verify or update the name of the target server, right-click on the project in Solution Explorer, select Project Properties,click on the Deployment tab, and then enter the name of the server.
I have checked in task manager & SQLBrowser is running. Why am I getting this error?
I was able to get the SQL Server instances on my computer this way:
Start Menu
Microsoft SQL Server 2008 or your version
Server Installation Center
Admin login
Select "Tools" from left menu
Select "Installed SQL Server features discovery report"
You then get a nice HTML web page. You want to look for Database Services. You should see an instance name. Mine is called "SQLEXPRESS." So the combination of server name and instance would be MYCOMPUTER\SQLEXPRESS given that my computer name is MYCOMPUTER.
BTW, the default instance name is MSSQLSERVER.
Alternatively, you can get it from your registry. Just run regedit and look for this key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL
Check that the SQL Server service itself (or MSSQLSERVER) is running. Also check the connection string.
If you want to deploy the project to a named instance of Analysis Services on the local computer, or to an instance on a remote server, change the Server property to the appropriate instance name, such as <InstanceName>.
https://learn.microsoft.com/en-us/analysis-services/multidimensional-tutorial/lesson-2-5-deploying-an-analysis-services-project?view=asallproducts-allversions
You need the server name and the instance name.
Open port 2382,2383 to server solve this issue for me.
Typically I remote into a machine with IP Address 00.00.00.00 and then I have an account in a domain, let's call it myspecialaccount\firstname.lastname.
Then I use Windows auth to connect to SQL Server instance for example:
ABCLACSQLC123\DEV04A
So my question is HOW can I connect from my laptop through SSMS directly to the machine (pending ports are open etc..)
In order to use Windows Authentication, you'd have to add the credentials you use to login to the laptop as a "Login" to the SQL Server. That can only be done if
You login to your laptop with a domain user and
The user is in the same domain in which your SQL Server instance resides
Otherwise, you have no choice but to use SQL Server Authentication.
In this case, you login to your laptop with a user in "Corp" domain, but SQL Server instance is in "Services" domain. So it won't work. Unless I think both domains are part of the same Forest.
Look at this answer : https://stackoverflow.com/a/1615431/3317709. There is no trick to login, unless you get rid of the "Network related..." error. If you are getting this error, SSMS is not even able to find your server let alone logging into it. Once you get "Login failed..." error, from that point, we can tinker and try to get thru using your windows auth.
Try creating a shortcut to runas.exe, pointing to SSMS.
C:\Windows\System32\runas.exe /netonly /user:myspecialaccount\firstname.lastname "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"
(The path to your SSMS exe may vary.)
When you double-click the shortcut, this will open up SSMS. You should then be able to connect to your instance (ABCLACSQLC123\DEV04A) as if it were on your local machine.
See here for more info on the runas command: https://technet.microsoft.com/en-us/library/cc771525.aspx
Install SQL Server Management Studio Express on your laptop. Microsoft has made the download link obscenely hard to find on their own site, but I did manage to find it here. Download the one for your system, probably x64.
Installation isn't much easier. Once everything is extracted, run the program, and switch to the installation tab, and choose "Standalone installation or add new features". Continue along the installation, and just install the management tools.
Once installed and running, use the Connect to Server dialog (it should open when you start the program, but if it doesn't, it's the first option under the File tab), and target wherever you want to connect (IP or server name should both work). If your laptop also authenticates to the same server that handles Windows authentication for your database, you can use Windows authentication, otherwise, you'll have to create a SQL Server account to use for login.
I am learning how to use the Service Broker of SQL Server 2008 R2. When following the tutorial Completing a Conversation in a Single Database. Following the Lesson 1, I have successfully created the message types, contract, the queues and services. Following the Lesson 2, I have probably sent the message. However, when trying to receive the message, I get the NULL for the ReceivedRequestMsg instead of the sent content.
When looking at the sys.transmission_queue, the transmission_status for the message says:
An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
I have installed SQL Server using the Windows login like Mycomp\Petr. I am using that login also for the lessons.
Can you guess what is the problem? What should I check and or set to make it working?
Edited 2012/07/16: For helping to reproduce the problem, here is what I did. Can you reproduce the error if you follow the next steps?
Firstly, I am using Windows 7 Enterprise SP1, and Microsoft SQL Server 2008 R2, Developer Edition, 64-bit (ver. 10.50.2500.0, Root Directory located at C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL_PRIKRYL05\MSSQL).
Following the tutorial advice, I have downloaded the AdventureWorks2008R2_Data.mdf sample database, and copied it into C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL_PRIKRYL05\MSSQL\DATA\AdventureWorks2008R2_Data.mdf
The SQL Server Management Studio had to be launched "As Administrator" to be able to attach the data later. Then I connected the SQL Server.
Right click on Databases, context menu Attach..., button Add..., pointed to AdventureWorks2008R2_Data.mdf + OK. Then selected the AdventureWorks2008R2_Log.ldf from the grid below (reported as Not found) and pressed the Remove... button. After pressing OK, the database was attached and the AdventureWorks2008R2_log.LDF was created automatically.
The following queries were used for looking at "Service Broker enabled/disabled", and for enabling (the Service Broker was enabled successfully for the database):
USE master;
GO
SELECT name, is_broker_enabled FROM sys.databases;
GO
ALTER DATABASE AdventureWorks2008R2
SET ENABLE_BROKER
WITH ROLLBACK IMMEDIATE;
GO
SELECT name, is_broker_enabled FROM sys.databases;
GO
Then, following the tutorial, the queries below were executed to create the message types, the contract, the queues, and the services:
USE AdventureWorks2008R2;
GO
CREATE MESSAGE TYPE
[//AWDB/1DBSample/RequestMessage]
VALIDATION = WELL_FORMED_XML;
CREATE MESSAGE TYPE
[//AWDB/1DBSample/ReplyMessage]
VALIDATION = WELL_FORMED_XML;
GO
CREATE CONTRACT [//AWDB/1DBSample/SampleContract]
([//AWDB/1DBSample/RequestMessage]
SENT BY INITIATOR,
[//AWDB/1DBSample/ReplyMessage]
SENT BY TARGET
);
GO
CREATE QUEUE TargetQueue1DB;
CREATE SERVICE
[//AWDB/1DBSample/TargetService]
ON QUEUE TargetQueue1DB
([//AWDB/1DBSample/SampleContract]);
GO
CREATE QUEUE InitiatorQueue1DB;
CREATE SERVICE
[//AWDB/1DBSample/InitiatorService]
ON QUEUE InitiatorQueue1DB;
GO
So far, so good.
Then the following queries are used to look at the queues (now empty when used):
USE AdventureWorks2008R2;
GO
SELECT * FROM InitiatorQueue1DB WITH (NOLOCK);
SELECT * FROM TargetQueue1DB WITH (NOLOCK);
SELECT * FROM sys.transmission_queue;
GO
The problem manifests when the message is sent:
BEGIN TRANSACTION;
BEGIN DIALOG #InitDlgHandle
FROM SERVICE
[//AWDB/1DBSample/InitiatorService]
TO SERVICE
N'//AWDB/1DBSample/TargetService'
ON CONTRACT
[//AWDB/1DBSample/SampleContract]
WITH
ENCRYPTION = OFF;
SELECT #RequestMsg =
N'<RequestMsg>Message for Target service.</RequestMsg>';
SEND ON CONVERSATION #InitDlgHandle
MESSAGE TYPE
[//AWDB/1DBSample/RequestMessage]
(#RequestMsg);
SELECT #RequestMsg AS SentRequestMsg;
COMMIT TRANSACTION;
GO
When looking at the queues, the Initiator... and the Target... queues are empty, and the sent message can be found in sys.transmission_queue with the above mentioned error reported via the transmission_status.
alter authorization on database::[<your_SSB_DB>] to [sa];
The EXECUTE AS infrastructure requires dbo to map to a valid login. Service Broker uses the EXECUTE AS infrastructure to deliver the messages. A typical scenario that runs into this problem is a corporate laptop when working from home. You log in to the laptop using cached credentials, and you log in into the SQL using the same Windows cached credentials. You issue a CREATE DATABASE and the dbo gets mapped to your corporate domain account. However, the EXECUTE AS infrastructre cannot use the Windows cached accounts, it requires direct connectivity to the Active Directory. The maddening part is that things work fine the next day at office (your laptop is again in the corp network and can access to AD...). You go home in the evening, continue with Lesson 3... and all of the sudden it doesn't work anymore. Make the whole thing seem flimsy and unreliable. Is just the fact that AD conectivity is needed...
Another scenatio that leads to the same problem is caused by the fact that databases reteint the SID of their creator (the Windows login that issues the CREATE DATABASE) when restored or attached. If you used a local account PC1\Fred when you create the DB and then copy/attach the database to PC2, the account is invalid on PC2 (it is scoped to PC1, of course). Again, not much is affected but EXECUTE AS is, and this causes Service Broker to give the error you see.
And last example is when the DB is created by a user that later leaves the company and the AD account gets deleted. Seems like revenge from his part, but he's innocent. The production DB just stops working, simply because it's his SID that the dbo maps too. Fun...
By simply changing the dbo to sa login you fix this whole EXECUTE AS thing and all the moving parts that depend on it (and SSB is probably the biggest dependency) start working.
You would need to grant receive on your target queue to your login. And it should work!
USE [YourDatabase]
GRANT RECEIVE ON [dbo].[YourTargetQueue]
TO [Mycomp\Petr];
GO
And you also need to grant send for your user, permission on Target Service should be sufficient, but let's enable on both services for the future.
USE AdventureWorks2008R2 ;
GO
GRANT SEND ON SERVICE::[//AWDB/1DBSample/InitiatorService]
TO [Mycomp\Petr] ;
GO
GRANT SEND ON SERVICE::[//AWDB/1DBSample/TargetService]
TO [Mycomp\Petr] ;
GO
We deployed a VB.Net application on a customer's computer that contains SSRS reports.
The application connects to the SQL Server database in the app without any problems. We installed SQL Server Data Tools so we could deploy the reports (rdl) and data source (rdl) files up to the report server. These deploy without any problems.
In SQL Server Data Tools we can "Preview" the reports without any problems as well.
We do run into a problem when attempting to view the report from Internet Explorer (run as an administrator).
We get the following error:
Cannot create a connection to data source 'DataSourceReports'
(this is the name we used for the TargetDataSourceFolder)
error:40 - Could not open a connection to SQL Server
We also get the same error when the app we deployed runs the reports.
Please let us know what is not set up correctly on the SQL Server side.
A likely possibility is that you are experiencing a double hop authentication problem. It's not clear from your explanation, but is the SQL Server database on a separate server from the report server? If so, then your credentials allow you to connect to the report server but Windows integrated security does not pass those credentials on to the SQL Server database if you are using NTLM on the report server. The report server tries to use Kerberos on your network to authenticate by way of ticketing to the SQL Server database, but you must have this configured correctly on your network. See this article if you want to use Kerberos: http://technet.microsoft.com/en-us/library/ff679930(v=sql.100).aspx.
Another (easier) solution is to open the data source on the report server and change the authentication to use stored credentials. Make sure the credentials you use have read permission on the SQL Server database. The downside of this approach is that you cannot use row-level security in your report by user unless you design your report to capture user information and set up the query or a filter on the dataset to restrict data by user. If that's not a concern, the stored credentials are easy to set up and maintain - and you're going to have to do this anyway if you want to use caching, snapshots, or subscriptions. For more information on stored credentials, see http://msdn.microsoft.com/en-us/library/ms159736.aspx.