The connection to SQL Workbench/J gets disconnected very frequently. Where can I change the settings so that it does not lose the connections for atleast an hour.
Thanks
This works for me with using PostgreSQL...
Go to Connection Window
Select the connection you want to keep alive
Click the "Connect scripts" button
Write "Select 1" in the third box titled "Statement to keep connection alive"
Write "1m" in fourth box titled "Idle time"
SQL Workbench/J (screenshot)
What OS are you using and what type of database are you connecting to?
I had the same issue using Windows connecting to a Redshift database. I followed the instructions on Amazon doing the following:
Edit (or otherwise create if not already existing in my case) the values for the following registry settings under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:
KeepAliveTime: 30000
KeepAliveInterval: 1000
TcpMaxDataRetransmissions: 10
Reference here: http://docs.aws.amazon.com/redshift/latest/mgmt/connecting-firewall-guidance.html
Related
Is it possible to change your active/default database connection in SQL Workbench/J while still under a single connection profile? There are times I am connected to a database server with multiple databases and I would like to switch my active database without having to use a USE statement, specify the full 3 part naming convention, or switch connection profiles entirely. In SSMS, there is a simple drop-down menu to easily switch between different databases. Just wondering if there is something similar in SQL Workbench/J that I'm just missing.
There is an experimental feature to enable a dropdown with the available databses in the main window.
If you run
WbSetDbConfig gui.enable.dbswitcher=true;
in a SQL editor tab when connected to a SQL Server database, then you should have a dropdown to switch the current database after restarting SQL Workbench/J.
It will essentially issue a USE in the background for the current connection when using SQL Server.
I have created an Amazon RDS DB instance. I can connect to it and perform operations with SSMS. I can also bind to it using Entity Framework DB-first and generate my model. However, when I run my app, using the same connection string that was generated in the data access project, I get a "the network path was not found" error while trying to establish a connection to the DB.
Let me be clear: the db exists, the right ports are open, and the connection string is correct. I am the only one connecting to the database and the status is "available".
So what's going on? Has anyone experienced something like this?
Let me also further mention that I have already checked the usual things like internet connectivity, firewall rules, state of the database, etc.
well it started working all of a sudden. So I guess this problem will only pop up again in production or something.
I have a SQL Server 2008 R2 Express database.
I have written a Delphi application that uses a TADOConnection object to connect to the database. It works just fine on my computer. It fails to connect from other computers on the network.
It gives the error message:
Cannot open database "PeopleNetLink" requested by the login.
I have found all sorts of questions about this error message. I have found none that used SQL Server authentication and worked on one computer and not on others.
My connection string is
Provider=SQLNCLI10.1;
Integrated Security="";
Persist Security Info=False;
User ID=PNetLink;
Initial Catalog=PeopleNetLink;
Data Source=W1CNVS02\SQLEXPRESSPAY12;
Use Procedure for Prepare=1;
Auto Translate=True;
Packet Size=4096;
Initial File Name="";
Use Encryption for Data=False;
Tag with column collation when possible=False;
MARS Connection=False;
DataTypeCompatibility=0;
Trust Server Certificate=False;
Server SPN=""
Further experimentation reveals that if I log on to another computer as an admin, the program will log in successfully. This tells me that it is not using the user ID specified in the connect string. Now the question is "why not?"
This is a bit of a long-shot, as I don't have Sql Server 2008 installed, only the 2014 version. And maybe you've tried this already, but I spent hours on this problem before I found the step I was missing.
Assuming a utility like MS's PortQry shows the server's local network firewall is open and that your edition of 2008 comes with a copy of Sql Server Management Studio installed:
Start SSMS on the server,
Right-click the Sql Server's Properties
In the Properties pop-up, click the Connections tab
Check the checkbox "Allow remote connections to this server."
In some Sql Server editions, "Allow remote connections ..." is not check by default, which seems to square with marc_s's comment.
Update: Regarding your added "This tells me that it is not using the user ID specified in the connect string.":
If you open the DFM as text and hand-edit the connection string so that the "User ID" has a completely bogus value, then go back to the connection string builder, you should find two things:
The Enter information to log on to server reverts to Use a specific user name and password, so if you then click Test connection, the test unsurprisingly fails.
If you then select Use Windows NT Integrated security and click Test connection again, the test succeeds.
From 2., it is evident that the "User ID" in the connection string is ignored when using Windows authentication. That doesn't seem surprising to me, since the point of using Windows authentication is that the credentials used are those of the logged-in Windows user. You've already established that if you log in on the other computer as an admin (I assume you mean a Windows administrator account), the connection succeeds, so I'd have thought that the non-admin account needs to be added to the Sql Server's recognised users if you're wanting to connect using that ID (though I confess it's not at all clear to me whether you're actually trying to connect using Windows authentication of a specific Sql Server account).
If you're still stuck try using e.g. the Microsoft OLE DB Driver for SQL Server instead of the SQL Server Native Client. You might also single-step through this article:
https://social.msdn.microsoft.com/Forums/en-US/523c7b7e-6216-4790-87cb-945f3c1f4c5e/can-not-connect-to-microsoft-sql-server-express-2012?forum=sqlexpress
Also, google
sql server express 2008 remote "secpol.msc"
and note articles such as this one
https://social.msdn.microsoft.com/forums/sqlserver/en-US/1f5221bf-f5c3-4307-836b-a4f9dc07f02f/very-strange-remote-connection-issues
Here is my situation. I have an application (Mirth Connect) running on the same server as SQL Anywhere 11. There is also another server on the same network running SQL Anywhere 11. I need to connect to both of them. They are both using the same SQL Anywhere "Server Name".
I need to use a JDBC connection to connect to either of them at any given moment. I can connect to the local instance just fine.
I tried to set up an ODBC connection to the remote server. When I test the connection it says it is all good. Then when I try to run a query I notice I am connected to the local server. It must be because both SQL Anywhere servers are using the same "Server Name".
How do I force the ODBC connection to connect to the Remote server?
Thank you!
You need to specify the IP address (and port, if not using the default) in the connection string. Your connection string must contain the LINKS parameter, with (at least) the following options:
LINKS=tcpip(HOST=<remote IP address>;PORT=<remote port>;DoBroadcast=None)
If the remote server is using the default port number, 2638, you don't need to specify the port number in the connection string. DoBroadcast=None tells the client library that it should make a direct connection to that host. The default (for version 11 and older) is to broadcast on the network looking for that server name, and whichever server responds first wins. Since there is a server on the local machine, it is very likely to respond first.
For version 12 and up, you can replace the entire LINKS parameter with the new HOST parameter:
HOST=<remote IP address>:<remote port>
which will have the same behaviour as the LINKS parameter above.
P.S. It is recommended that you give each server a unique server name, thus avoiding the need to hard-code the IP address of the host. Not to mention that you must be using some trickery to fool the second server into either (a) thinking its name is unique, or (b) not checking to see if it's unique, which it does by default. If you use unique server names, you don't need this extra stuff.
Disclaimer: I work for Sybase in SQL Anywhere engineering.
this is really two questions in one I guess.
We've developed a .Net app that accesses an Oracle database, and have noticed that after changing the user's Oracle password, the app continues to work for a short time with the old password in the connection string. Presumably this is something to do with the way existing connections are pooled?
When first investigating this we tried turning off pooling in the connection string, however the app wouldn't work, throwing the error "Unable to enlist in a distributed transaction" at the point it tries to open a connection. While we probably wouldn't want to turn off connection pooling in a production app, I'm curious as to why MSDTC seems to need it?
We are using Oracle 11g (11.1.2) and latest ODP.Net (11.2 I think).
Thanks in advance
Andy
Please see some of the finding below:
For Question One: (application still connected with old DB password)
If we connect the database with connection pooling option, connection pool manager would create and maintain the number of connection sessions when first calling the open or close of OracleConnection object. (number of this connection sessions depend on "min" & "max" pool size in connection string). In Oracle, I think you could check active session like:
SELECT s.inst_id,
s.sid,
s.serial#,
p.spid,
s.username,
s.program
FROM gv$session s
JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id
WHERE s.type != 'BACKGROUND';
And according to Oracle doc, this connection pooling service will close the connection sessions after 3 minutes of in-active state. [ http://docs.oracle.com/html/E10927_01/featConnecting.htm ]
So the most possible reason could be, your application still
connected to the database by using this Pool and still connected for
a short time, even after you changed the database password.
There could be also one possibility of "Oracle Client Cache"
feature in ODP.net. But not quite sure, you can check at, [
http://www.oracle.com/technetwork/issue-archive/2008/08-jul/o48odpnet-098170.html ]
For Question Two: (why MSDTC needed)
If you are using nested Database connection in your code, it will be promoted to DTC. [ http://petermeinl.wordpress.com/2011/03/13/avoiding-unwanted-escalation-to-distributed-transactions/ ] Actually there was Oracle Service for Microsoft Transaction Server (OraMTS) act as among ODP.net, DTC, and Oracle Database.
But you didn't happend this problem (MSDTC) before disabled the connection pooling. It seems like your code is reusing the same connection out of undelining connection pool, and it might eliminate the need to promote DTC. There was similar question on StaffOverflow. [ Why isn't my transaction escalating to DTC? ]