I have a SQL Server on a VLAN that I have read permissions to and I need a SQL Server instance on an external network to be synced. I only have read permissions and our partner won't allow us to configure replication so that's not an option. On top of all that because it's on a vlan the external SQL Server can't connect to it directly.
I think my best bet now is simply to write an application (most likely in C#) that will detect changes and push them to the external SQL Server. This approach doesn't seem ideal.
Are there any out of the box ways to do this or any tried and true methods?
Related
My organization had a security audit and was told that we need to DISABLE the "allow remote connection to this server" option for all of our SQL Servers. What impact would this have on connection to the SQL Server via Management Studio (SSMS) from a client machine/desktop or from a web app that might use a connection string or any other external app? All of the documentation I see regarding connectivity issues to a SQL Server seem to include "ENABLING" this option as a solution. Is there a workaround that will allow us to disable it but still allow the access we need from the target clients?
We have multiple versions that we would be doing this on 2012, 2014, 2016 and 2017.
The "allow remote connection to this server" option in SSMS (Server Properties-->Connections) is actually the remote access configuration option. This option is often mistaken for enabling remote network connectivity via SQL Server Configuration Manager, which might be what you've read.
The remote access option is a long deprecated feature that will be removed in a future SQL Server version. It will likely have no impact but your environment may be atypical so you may want to first test in a pre-prod environment before making the change in prod.
Below is the excerpt from the documentation.
The remote access option controls the execution of stored procedures
from local or remote servers on which instances of SQL Server are
running. This default value for this option is 1. This grants
permission to run local stored procedures from remote servers or
remote stored procedures from the local server. To prevent local
stored procedures from being run from a remote server or remote stored
procedures from being run on the local server, set the option to 0.
I need to discover the running db2 servers in a network.
I tried to connect to all servers in the network using the JDBC connection. But the problem is while using JDBC, we need to specify the database name in the URL. As of now, I tried to connect to the SAMPLE database. But if a db2 instance does not have the SAMPLE database, the connection will fail.
So I want to know the other possibilities to discover db2 servers in a network and also Is there any way to connect to the instance of the db2 server unlike connecting to a particular database(Similar to SQL - Connecting to an instance using port only)
Db2 administration server (DAS) has the corresponding functionality. Refer to the following link:
Discovery of administration servers, instances, and databases.
Note, that DAS is deprecated and may be removed in future Db2 releases.
My objective is to use the migration tool in SQL Developer to migrate 2 SQL Server databases to Oracle. I am attempting to connect to a SQL Server database at a remote location using Oracle SQL Developer 4.0.
I have installed jtds.1.3.0.jar per instructions, and get the SQL Server and Sybase tabs in the connection properties window.
I have entered the user, pw, hostname, port, and database name. When I try to Retrieve Database, or connect, I get the error message:
Status : Failure -Test failed: I/O Error: DB server closed connection.
The SQL Server DBA tells me her error logs contain the following error message:
Encryption is required to connect to this server but the client library does not support encryption; the connection has been closed. Please upgrade your client library. [CLIENT: (my computer's IP address)] Error: 17835, Severity: 20, State: 1.
When I look at SQL Server documentation about this error message, it talks about certificates and SQL Server Connection Manager. Some relevant information to show that I've covered the basics:
Using the same connection parameters, I am able to connect to the SQL Server database using Toad for SQL Server.
Using the same connection parameters, a DBA set up an Oracle Transparent Gateway, and I can connect to the SQL Server database using the gateway and a database link. (As far as I know, neither of these methods required a certificate to connect.)
Both of these use ODBC; SQL Developer uses jdbc with TCP/IP.
The DBA assures me TCP/IP connection is turned on for the SQL Server databases.
I have gone into the XML file where SQL Developer stores the connection string. It has the form jdbc:jtds:sqlserver://sql-xxx-xxx.mw.nos.xxx.com:1433/my_db, which looks correct. I have tweaked it by adding the instance name, but no difference. The database has a default instance name, anyway, so it shouldn't be necessary.
A co-worker has been able to connect to a local SQL Server database on the same machine where SQL Developer was running (both on his laptop).
As a workaround, I am also pursuing the possibility of installing SQL Server on a local workstation, and copying the databases there for processing, but I don't know if I can get approval. If you know another tool for migrating from SQL Server to Oracle, please also let me know.
Thanks in advance.
In an attempt to do some basic profiling on our Azure SQL Server (V12) we enabled Auditing using the Azure portal.
Not many seconds later I had an angry developer on my hands that could not connect to the database using his client (HTML5 page).
I really couldn't see the connection, but since enabling auditing was the only change, I tried disabling Auditing again, and sure enough now the client could connect.
Further info:
I could access the SQL server using SSMS just fine.
The problem was only on the TEST environment from the customers network, not from our DEV environments (which is from Visual Studio on the developers own laptops).
Can anyone tell me why enabling auditing can break this? We tried doing it on other databases too, and sure enough: when I enabled auditing, the connection could not be established...
According to this page, if you want auditing on, the FQDN connection strings need to be changed:
Original server FQDN in the connection string: (server name).database.windows.net
Modified server FQDN in the connection string: (server name).database.secure.windows.net
Our MS Access application with linked tables to SQL Server 2005 is slow when using Windows Authentication from Windows XP clients.
We've been running it successfully using SQL Server authentication, but now we want to move to Windows Authentication for better security control.
Setup:
Database server: Windows 2003 Server, SQL Server 2005 SP2
Client: Windows XP SP3, SQL Server ODBC driver v2000.85.1132.00
MS Access application: MS Access 2003
Connection string:
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Only the TCP/IP network protocol is enabled on the server.
The slowness does not happen in these situations:
App on DB server, SQL Server Authentication
App on DB server, Windows Authentication
App on Windows XP client, SQL Server Authentication
SQL Server Management Studio on client, Windows Authentication - I did a small test with running 15 queries in SQL MS. This went fast and did not cause any logon/logoff events in the Security event log on the server.
I've analyzed the slowness using SQL Server Profiler and the event log on the server and it seems to come down to this:
The application runs a query
A new connection to SQL Server is opened (visible in SQL Server Profiler)
The identity of the user is verified (visible in the Security event log on the server, a logon/logoff event happens). This takes several hundreds of milliseconds.
The query runs on SQL Server
Results are returned to Access
This happens for every query. Some of the forms run +- 10 queries when showing a new record (updating sub forms, loading values for combo's etc). This results in very slow performance.
Of course setting up a new connection to SQL Server for every query isn't necessary, and reusing connections might solve the issue. I've been looking around for information on how to make sure Access/ODBC does proper connection pooling. I found these MS KB articles:
Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application
I've tried calling the SQLSetEnvAttr function from the main form of the Access application, but this didn't improve results.
Any help is greatly appreciated.
The first question I have is: are you running a domain controller? This may sound like a crazy question, but I just want to make sure. Although is less and less common, I've seen organizations run Windows networks with workgroups and "pass-through" authentication. The symptoms you describe are the same as would be observed on a network that is set up in this fashion.
Assuming you do have a proper domain set up, you must have a problem somewhere in the Named Pipes network stack. Named Pipes is the default protocol if you're using Windows authentication. It's not a bad idea to get to the bottom of this if you have the time, but if you just want to fix your performance problem, then I would force the TCP/IP protocol in your connection string:
DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Note the addition of the tcp: prefix. I got this syntax from Jon Galloway's blog. TCP/IP is the default protocol for SQL Server Authentication. You can also make the protocol switch by disabling Named Pipes support on the server, but this is more of a hassle and could cause other unanticipated problems.
Check Microsoft SQL Server Native Client
at http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en