FreeTDS unixODBC concurrent connections - sql-server

I'm using Golang with FreeTDS using the ODBC driver from brainman (http://code.google.com/p/odbc)
Everything works great, until I stress test the box.
Then I get the following error:
{01000} [unixODBC][FreeTDS][SQL Server]Unable to open socket
SQLDriverConnect: {08001} [unixODBC][FreeTDS][SQL Server]Unable to
connect to data source
It seems that when I try to launch multiple concurrent requests against the FreeTDS / unixODBC drivers, it fails. Is this something that is workable, or is unixODBC and FreeTDS not useable in production environments?

This sounds similar to an issue that I ran into. FreeTDS/ODBC on CentOS7 connecting to an SQLServer2005 database. I ended up creating 6 separate FreeTDS/ODBC DNS entries to have 6 discreet database connections available to use in order to resolve this issue (they were all just numbered duplicates of each other--$db, $db2, $db3, etc). It's not a great solution, but it does work (I was migrating a really old system, so my options were limited). I'd be very interested if there is a better solution than mine.

Related

Connect to Ms SQL with RODBC without dsn

I'm trying to set up a connection from ubuntu to mssql server with the RODBC package.
I did make it work with RJDBC but read the speed might be much slower than ODBC so I wanted to test it.
I don't have a dsn available, ip port databasename usr pwd is all the information I can use.
The code used with RJDBC which works is:
drv <- JDBC("com.microsoft.sqlserver.jdbc.SQLServerDriver",
"/media/sqljdbc4.jar")
RJDBC::dbConnect(drv, 'jdbc:sqlserver://ip:port;databaseName=databasename', 'usr', 'pwd')
Tried alot around browsing different syntaxes but could not make it work.
RODBC::odbcDriverConnect('driver={SQL Server};server=ip:port;database=databasename;uid=usr;pwd=pwd)
Gives me the error: [unixODBC][Driver Manager]Data source name not found, and no default driver specified
Do I need to download drivers to the ubuntu machine? Thought they were included with the package.
The RODBC package doesn't include drivers. That would be unwieldy given how many possibilities there are.
see https://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf
"connection to the particular DBMS needs an ODBC driver : these may
come with the DBMS or the ODBC driver manager or be provided
separately by the DBMS developers, and there are third-party
developers"
Microsoft provides drivers for Ubuntu:
https://www.microsoft.com/en-us/download/details.aspx?id=50419
You can add dsn entries to the /etc/odbc.ini file in most linux distros. See this for ubuntu https://help.ubuntu.com/community/ODBC

Connecting to database via ODBC

I have running a 32-bit software(Lexware) running on a 64-bit server that uses SQL Anywhere 12 database. Several clients a connecting via ODBC to this database.
After one employee updated the server one client stopped working correctly. PyOdbc gave the message that the architecture of the driver does not correspond the the one of Lexware.
It seems that I am using the 64-bit ODBC driver, which does not work with a 32-bit Lexware. So I tried to use the 32-bit ODBC driver. The client is using Windows7 64-bit.
I went to the 32-bit ODBC Data Sources
Clicked on Add
Chose "SQL Anywhere 12"-driver
Clicked Finish
Then an error messages appears: "The setup routines for SQL Anywhere 12 could not be found. Install the driver again."
I click ok. Another message appears. "Error found: Component could not be found in the registry.
I then installed the whole sybase drivers again.
But I get the same error. I do not know what to do anymore. I also tried several other things. What I find curious is that everything worked before. All the other clients also work. Just this one does not. I need this to work for my company.
How can I fix this?
You need to install the 32-bit version of the Lexware ODBC drivers. You also need to install the 32-bit version of the client you are using to query the databases.
You cannot mix 32 and 64 bit code in one process.
I found the solution.
Under "HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/ODBC/ODBCINST.INI/SQL Anywhere 12"
The Strings "Driver" and "Setup" were missing. I added the path to the 32-bit ODBC drivers. Now everything works again.

NodeJS: How to connect to MSQL database using Windows Authentication/trustedConnection from Mac

I'm building a NodeJS app on my Mac and I need to connect to a MSSQL database.
Using the node module mssql, I'm able to connect to the server. But authentication fails because the database server requires the use of Windows Authorization or 'trustedConnection'. If I could use the Microsoft Driver for Node.js for SQL Server with mssql, I could provide a true value for 'options.trustedConnection', but that driver is Windows only.
Is there any way to do what I'm attempting? I don't see a way with the other drivers/node modules (tedious, tds, etc) to provide a connection string that would set trustedConnection to true or use Windows Authentication.
I just successfully connected to the SQL Server from Ubuntu 14.04.
I use FreeTDS as the driver, and unxiODBC as the driver manager, node odbc as the Node.js module to connect. I think this might be used on OSX as well.
More information can see this link. I blog it, and hope can save someone else's time.
But I need to do more research because I want to use this node module mssql to connect. mssql uses tds or tedious as drivers.

Methods of finding SQL Servers in a network programatically

I'm trying to detect Microsoft SQL Servers in a network. First of all, one would read Microsoft docs on how to do it, right? So I read about ODBC's SQLBrowseConnect and went with it. I found all SQL Server Express Editions I had installed and was happy, until I gave finished product to client for testing. They say it didn't find any servers.
Turns out that depending on operating system, ODBC SQL Server client used and other, unknown to me factors, I can detect some or none of running servers. When compared to output of sqlcmd -L my detection with SQLBrowseConnect looks bleak. We were moving my app between computers and depending on SQL Server ODBC driver version, SQL Server Native Client version (I've used both) and Windows version, results were different, but some servers were not detected at all, while sqlcmd detects them.
I then tried this method of broadcasting UDP packet of 0x02 to port 1434 where Browser listens, but I got no more than SQLBrowseConnect.
By the way: I tried today Management Studio on two of my computers - same version, different Windows. On Win7 detected 3 servers, on Win2003 detected 6 at the same time.
There's obviously more methods to detect SQL Servers, because on computers where I can't get any results, my colleague gets all servers, but he's using Embarcadero Delphi as a component, which, I believe, uses .NET provider.
I just read there's WMI method too, but I believe you have to supply user and password of target computer, which obviously is useless, as I would need users to supply multiple passwords for multiple servers, which they don't even know. Unless I misunderstand something.
Anyway, please share any method that can be implemented in c or c++, anything. Please note: I can't ask for passwords to computers to connect with WMI.

Invalid packet length when connecting

Another team in my company commissioned a new server and installed Netezza on it, along with a bunch of internal programs. All of their programs that connect to Netezza are now giving this error:
A connection error has occurred: Invalid packet length
Attempting to connect to the database using a GUI such as DbVisualizer or RazorSQL gives the same error. Connecting to the "old" server still works fine. One of the differences between the two boxes is the Java version, 1.5 on the old one and 1.7 on the new one... not sure if that is relevant. (I'm not a Netezza expert, not really a Netezza user either!)
Any ideas?
I was under the impression from the start that both NZ1 and NZ2 were running the same Netezza version. Apparently that was not the case.
The new NZ2 host was running against version 6.0 whereas NZ2 was running against 3.0. The JDBC driver we were using for NZ2 was 3 major versions too old. This also explains why the nzsql client on NZ1 couldn't connect to the NZ2 host.
We updated to the latest JDBC driver from IBM and can now connect just fine.

Resources