Can someone tell me why the code below performs very slow?
The last sentence takes more than 6 seconds.
I am trying to read data from a SQL server with C++.
std::string connectString("Provider=SQLOLEDB; Data Source=XXX;Initial Catalog=YYY;Integrated Security=SSPI;");
_ConnectionPtr Connection;
CoInitialize(NULL);
pConnection.CreateInstance(__uuidof(Connection));
HRESULT hr=Connection->Open(connectString.c_str(),"","",adConnectUnspecified);
Adding the portnumber did the trick!
std::string connectString("Provider=SQLOLEDB; Data Source=XXX,1430;Initial Catalog=YYY;Integrated Security=SSPI;");
Here are some points to check:
Between your datasource and your application lies a network connection, e.g. a SMB share. These tend to be slow.
Try to find out if some registry settings work against you, forcing too small net packets or other kinds of throttles. These things depend on the framework version.
A virus scanner wants to be your friend.
Here is an example how the firewall can disturb: Very slow connection to SQL Server 2005 only if using ADO.NET with SqlClient
As the firewall blocks the requests, the system chooses some pipe streaming after a timeout.
I hope one of those will help you :-)
For me the answer was to enable TCP/IP using Sql Server Configuration Manager (I'm not sure how it managed to connect before; only Shared Memory was enabled ¯\_ (ツ)_/¯ )
Related
I have a Python package that I am able to run successfully on an Azure Data Science Virtual Machine. However, when I push it to Azure as a Function, I cannot successfully make a database connection. I was getting an error that the ODBC Driver 13 for SQL Server was not supported, so I changed the driver to ODBC Driver 17 for SQL Server and now I am NOT getting an error, but no data is being returned for a query that I know should return data.
Is there any other reason that data would not be returned? Firewall issues? do I need to add a binding? Do I need to separate out the connection string to feed each part (e.g., Driver, UID, PWD) into pyodbc.connect() separately? Right now I am feeding it in like this:
setting = os.environ("CONNECTIONSTRING")
conn = pyodbc.connect(setting)
This query works fine returning data when I run it on the VM using this code, just not as a Function.
(Note, this is different from my previous post regarding reading the Azure App Setting. That problem has been solved).
There are many parts where this could be breaking.
I'd suggest start by having a Profiler or Extended Events trace on your SQL Server to verify whether a connection is even being established. If not then you need to work through the the various points of connectivity to find out where it breaks. The identity, firewall, NSGs etc might all come into play here.
Once you see a connection then you can play with permissions to ensure that your query then returns your data.
Without a full picture of your infrastructure and settings it is hard to pin it down further.
Turns out it was not a database connectivity issue like I thought it was; it was a code error.
Does anyone know if there is a way to force abort connection that is being established in background thread? Or at least define connect timeout?
A couple of notes
Leaving background thread running and just forgetting about it is not an option.
Went through source code and available properties - could not find anything related to the question.
Please be aware that FireDAC (Data Access Library) only describes the Technology from Delphi to simplify accessing Data on several Databases.
To define a Timeout on your connection, the Database Connection has to Support that.
Here is the Describtion for a Connectiontimeout in, for example, an Interbase Connection via FireDAC.
http://docwiki.embarcadero.com/Libraries/Berlin/en/FireDAC.Phys.IBBase.TFDIBService.ConnectTimeout
We're using glassfish 3.1.2 and it seems very brittle in terms of maintaining datasource connection pools through a database server restart or a break in network connectivity with the database (even a slight one).
It doesn't seem like it's particularly adept and re-establishing those connections and moving on.
We're using com.mysql.jdbc.jdbc2.optional.MysqlDataSource.
We're using connection validation.
Is there something else we're missing? Does anyone else experience this?
Same here.
Have you tried to configure the JDBC connection with autoreconnect?
Example: jdbc:mysql://localhost:3306/foo?autoReconnect=true
I guess everything is possible but I am wondering how easy is it for someone to hijack a connection string with a network packet analyzer or equivalent tool.
A winforms application fetches data directly from an MSSQL server.
(Supposing there are no webservices in the middle for extra protection)
1) Is it possible for someone with an analyzer to read the connection string as clear text?
2) The connection string could be protected with an SSL certificate?
3) The SSL certificate should be installed on the SQL server?
4) I already own an SSL certificate https Could I install it also for the SQL server?
5) The speed of the the return data, will be reduced due to SSL?
Thanks in advance
Yes. If they're on the same network as the packet sniffer (henceforth "the sniffer") and the connection string is in plain text it's easy. Using a switch instead of a hub will not make it any harder to do this.
still possible using a man-in-the-middle attack. Channel binding is designed to detect and prevent this, along with careful examination of the certificate received by the client. Client certificates would help strengthen this as well
yes it should
as long as the host name matches the sql server exactly it should work, otherwise you'll need a new cert.
it probably will reduce the speed but not by much. Benchmark it and see if the slowdown still gives acceptable performance; there's no other way to predict the impact with any degree of reliability.
One other thing: if the connection string is encrypted I can still analyze the packet to find your server's location and if the data being passed back and forth isn't encrypted I can still read it even if I can't connect to the sql server. I can also potentially modify it. This is why it's unusual for a SQL connection to exist over the internet and why it's usually either connecting to a DB on the same server, connecting via a local network, connecting via a VPN, or encrypting the whole data stream.
If it isn't encrypted, it can be read, yes. Note that the SQL Native Client may often perform a non-SSL based encryption (depending on lots of factors), but yes, it can also be encrypted with SSL; see technet. And yes, it slows things down slightly. The requirements for the certificate are all in the technet article. But please don't expose your db server to the internet...
Today we had a lot more activity than normal between our Ruby on Rails application and our remote legacy SQL Server 2005 database, and we started getting the error below intermittently. What is is? How can I prevent it (besides avoiding the situation, which we're working on)?
Error Message:
ActiveRecord::StatementInvalid: DBI::DatabaseError: 08S01 (20020) [unixODBC][FreeTDS][SQL Server]
Bad token from the server: Datastream processing out of sync: SELECT * FROM [marketing] WHERE ([marketing].[contact_id] = 832085)
You need to use some sort of connection pooling.
Windows itself (including Windows Server X) will only allow a certain number of socket connections to be created in a given time frame, even if you close them. All others will fail after that.
A connection pool will keep the same sockets open, avoiding the problem. Also, new connections are real slow.
This Microsoft article says:
Often caused by an abruptly terminated network connection, which causes a damaged Tabular Data Stream token to be read by the client.
Was the server network bound? I have no experience with SQL Server, but does it have a limit on the number of connections you can make?
Add the following to your script; the first statement you run:
SET NO_BROWSETABLE OFF