We are using SQL Server replication using RMO. We have SQL 2016 (Standard Edition) on the server acting as the publisher and SQL Server Express Edition as the subscriber.
Previously, the distributor and the publisher were on the same server and the replication was working.
We have a client application, the data needs to be synced with the server on a regular basis.
We have Transactional and merger replication set and rely on pull approach where the client application pulls the data on demand.
For security reasons, the client doesn't want to expose port 1433 (or any other port) on the publisher to the subscribers.
So, we decided to move the distributor on a remote server, so that the subscriber talks to the publisher via remote distributor. (The remote distributor can connect and talk to the Publisher.) However, I am getting an error when I try to sync.
Wanted to check if replication is possible when port 1433 is blocked for the subscribers?
If yes, can you provide me some sample code or pointers to it. If no, what are the different options that I can have?
Related
I have a mirror and witness setup with automatic failover setup. The server side of the mirroring works fine, when we take the network cable out the databases failover to the failover server.
The problem I have is that the connection string that I am using:
Driver={SQL Server};Server=WCFTEPATSQL01;Failover_Partner=WCFTEPATSQL02;Initial Database=DBForms;Trusted_Connection=SSPI;Network=dbmssocn;Pooling=false
is not sending the connection to the failover partner when the primary server is down. I can change the server address to the failover address and this will work but this is not what I should be doing.
The setup is classic asp on IIS 7.5.
Any help would be great as I have tried almost everything out there.
I have solved my own issue, it looks like the SQL Server driver didn't recognise the Failover Partner, I changed the connection string to:
Driver={SQL Server Native Client 10.0};Failover_Partner=WCFTEPATSQL02;Server=WCFTEPATSQL01;Database=DBForms;Trusted_Connection=yes;Network=dbmssocn;Pooling=false
and all is good.
We have sql 2000 databases on our internal network secured behind ISA Firewall. Up till now we have not opened tcp port 1433 to allow external sql traffic in or out. We also have a remote external website with a later version of sql on.
Is there any way to update the external database from our internal network without increasing the chance of anyone hacking into our internal network?
The Sync Framework does this for most cases. I'd recommend against opening up your firewall to allow anyone to connect to your database server - that's pretty much inviting hackers to own your data.
The Sync framework works natively with SQL Server 2000 SP4 and later - though you can probably find a provider for older versions if you try. By using a provider framework, Sync can in principle connect to any data source.
I have SQL Server 2012 Web Edition.
I want to configure High Availability on this Server.
Do I need to have another SQL Server to configure High availability?
How is SQL Server Native Client 11.0 is part of this?
I know this is a wide area question, but I am looking for a start on this.
Yes, for all high availability scenarios you need more than one server. As for high availability in the web edition, all you get is log shipping, so you will need to manually fail over to another server if your primary dies.
The native client is a combined ODBC driver and OLE DB Provider for SQL server. It doesn't in itself provide high availability, but it can be used, for example if you were using database mirroring, to provide the name of the mirror server for automatic failover.
I am currently unable to connect to my Azure SQL database from a separate remote standalone dedicated box in a private datacenter.
I have an Azure SQL database where I manage the list of IP addresses that can connect to this database. This has worked perfectly until now. I have recently set-up a new dedicated box in a private datacenter that needs to query the Azure SQL database at regular 5 second intervals, give or take.
The problem is, this dedicated box cannot establish a connection to the Azure SQL database, despite being able to connect to other remote FTP servers, MySQL servers, etc. The Azure SQL database does have the IP address of the dedicated box on the allowed connection list. Furthermore, I temporarily opened up a massive range of allowed IP addresses (0.0.0.0 -> 255.255.255.255) on the Azure SQL database to see whether this inability to connect may have resulted from IP blocking.
Does anyone have any suggestions or thoughts on what might be causing this and how I could begin debugging the situation better?
To clarify: I can connect to the Azure SQL database from laptops with individual IP addresses in my office and elsewhere, so long as they have been added to the database whitelist; I can make outward connections to remote FTP and MySQL servers from the dedicated box; I have tried to open-up a massive range of allowed IP addresses on Azure SQL with no luck.
Edit
C:\Users\graphite.rack.ID17157>osql -S v7o06blktw.database.windows.net -U XXXXXXX#v7o06blktw -P XXXXXXX
[SQL Server Native Client 11.0] Named Pipes Provider: Could not open a
connection to SQL Server [53].
[SQL Server Native Client 11.0] Login timeout expired
[SQL Server Native Client 11.0] A network-related or instance-specific error
has occurred while establishing a connection to SQL Server. Server is not
found or not accessible. Check if instance name is correct and if SQL Server
is configured to allow remote connections. For more information see SQL Server
Books Online.
To summarize.
Windows Azure SQL Database (formerly known as SQL Azure) works exclusively and only on TCP port 1433. It only support SQL Server Authentication, TCP connection and TDS protocol as of today.
In order to successfully establish connection to SQL Azure one must fulfil the following requirements:
Create SQL Azure server & Database
Setup SQL Azure Server's firewall rules to accept connections from the IP address of application that will connect to that server
Make sure the box (be it Virtual, or home, or whatever) has no blocking outbound TCP port 1433
Explicitly force encryption in connection string
Explicitly chose to not trust server certificate in connection string
Please note that many (if not all) ISPs (Internet Service Providers) and Hosters, as well as IT staff within companies DO block outgoing TCP Port 1433 due to the SQL Slammer worm. This outgoing port blocking appears to be one of the most faced issues of newcommers to SQL Azure.
UPDATE Nov. 2015
As of August 2015, there is preview feature that enables you to use Azure AD to authenticate to Azure SQL Database. You can read more on this new preview feature here: https://azure.microsoft.com/en-us/documentation/articles/sql-database-aad-authentication/
If you're using corporate network for internet access and facing this problem,
a simple way around this is to use your phone's mobile hotspot for internet access instead.
Be sure to disable your ethernet connection too, which may also be connected to the internet.
Spent hours on this issue. The fix for me was finally found to be my setting on the Xfinity firewall. I had it set to high. Once I changed the setting to low security, I could connect to the Azure sql database with no issues.
Is it possible to use external activation on sql express without going thru sql enterprise/standard?
I would like to send a message to sql express service broker, then have it notify my external application service running on the same box, in order to kick off a console app to pickup the message and process it. I do this already successfully from a remote Sql Enterprise db.
But now I need everything self contained on one box with Sql express, without using the remote Sql Enterprise.
However sql express has limitations so I'm wondering if I can use sql express as described in a stand alone configuration, without going thru Sql Enterprise. Thanks for your help!
You can do that, as long as the box sending the message is non-express edition.
The edition-related limitation of Service Broker is that a message must go through at least one non-express instance on its way from the sending service to the receiving service. There are no limitations on the External Activator service itself.