We've be using the activerecord-sqlserver-adapter gem with sqlserver 2008 and everything works great. We just tried to deploy our Rails 3 app against a new sqlserver 2014 db and I get an error that says:
Currently, only 2005, 2008, 2010, 2011, and 2012 are supported. We got back Microsoft SQL Server 2014 - 12.0.2000.8 (X64)
A quick look at github shows that a small update was recently made to the sqlserver_adapter.rd to resolve this issue. I tried to update the gem and it turned into a bit of dependency hell and eventually looked as though I'd have to upgrade to rails 4 (which I don't particularly want to do right now) in order to get this fix.
So I thought I make my first attempt at a monkey patch and created an .rd in my initializers folder that incorporates the the changes to add sqlserver 2014 support:
module ConnectionAdapters
class SqlServerAdapter < AbstractAdapter
SUPPORTED_VERSIONS = [2005,2008,2010,2011,2012,2014]
# === SQLServer Specific (DB Reflection) ======================== #
def sqlserver_2014?
#database_year == 2014
end
end
end
My intention was to simply override the several lines of code in sqlserver_adapter.rd with change in the fix on github. However when I try to deploy, I now get an UnitializedConstant Error referring to AbstractAdapter.
How can make this patch work? Or this there a better way to accomplish this task?
I found a much better solution than a monkey patch. Turns out the guys over at activerecord-sqlserver-adapter updated the various releases so I just had to specify the version 3.2 branch with the SQLServer 2014 support fix. The following line in my gem file resolved the entire issue and we are now connecting to SqlServer '14
gem 'activerecord-sqlserver-adapter', :git => "git://github.com/rails-sqlserver/activerecord-sqlserver-adapter.git", :branch => "3-2-stable"
I have also addressed this problem with the Ruby 1.8.6 setup that I inherited.
The solution is not really as high-tech as proposed here.
The adapter interface is located at C:\ruby\lib\ruby\gems\1.8\gems\activerecord-sqlserver-adapter-2.3.4\lib\active_record\connection_adapters and is called sqlserver_adapter.rb.
I modified the following code to appear as such:
class SQLServerAdapter < AbstractAdapter
ADAPTER_NAME = 'SQLServer'.freeze
VERSION = '2.3.4'.freeze
DATABASE_VERSION_REGEXP = /Microsoft SQL Server\s+(\d{4})/
SUPPORTED_VERSIONS = [2000,2005,2008,2012,2016].freeze
LIMITABLE_TYPES = ['string','integer','float','char','nchar','varchar','nvarchar'].freeze
LOST_CONNECTION_EXCEPTIONS = {
:odbc => ['ODBC::Error'],
:ado => []
}
LOST_CONNECTION_MESSAGES = {
:odbc => [/link failure/, /server failed/, /connection was already closed/, /invalid handle/i],
:ado => []
}
The only thing I did to modify the adapter code was change [2000,2005,2008] to [2000,2005,2008,2012,2016].
I then used the ODBC Datasource Administrator (32-bit) to configure to use the "SQL Server Native Client 11.0" for the Sql Server 2016 instance.
This last step is the really important one in the ODBC adapter setup.
The "SQL Server" adapter may default to a 64-bit connection which gives the following error when trying to connect to the database:
#<ODBC::Error: S1090 (0) [Microsoft][ODBC Driver Manager] Invalid string or buffer length>.
I am retrofitting an obsolete 2008R2 server set of legacy Ruby programs running on Apache to a new Windows Server 2016 setup, and don't have the luxury of debugging the legacy Ruby code to make it work with a newer version of Ruby and Ruby on Rails.
This low-tech solution fully meets our operational needs, budget and time constraints.
I did the following with v 4.1.8:
module ActiveRecord
module ConnectionAdapters
class SQLServerAdapter < AbstractAdapter
SUPPORTED_VERSIONS << 2014
# === SQLServer Specific (DB Reflection) ======================== #
def sqlserver_2014?
#database_year = 2014
end
end
end
end
Related
I've been trying to automate disabling dynamic ports in a new installation of SQL Server 2012 and setting a static TCP port. I can do this without an issue from the SQL Configuration Manager, but getting a script to do this is giving me more trouble. Luckily, I found someone that was looking to do the exact same thing here: MSDN Forums.
The code I'm using is the following:
Private Function setProperty ( ByVal path, ByVal value )
Set obj = GetObject(path)
errornumber = obj.SetStringValue(value)
If Not errornumber = 0 Then
WScript.Quit(errornumber)
End If
End Function
Set args = WScript.Arguments
If Not args.Count = 1 Then
WScript.Echo "ERROR: Invalid arguments"
WScript.Echo "Usage: cscript " & WScript.ScriptName & " "
WScript.Quit(255)
End If
' set TCP/IP port of SQLServer instance 'SQLSERVER_MATRIX'
setProperty "WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement:ServerNetworkProtocolProperty.InstanceName='SQLSERVER_MATRIX',IPAddressName='IPAll',PropertyName='TcpPort',PropertyType=1,ProtocolName='Tcp'", args(0)
' switch off dynamic ports
setProperty "WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement:ServerNetworkProtocolProperty.InstanceName='SQLSERVER_MATRIX',IPAddressName='IPAll',PropertyName='TcpDynamicPorts',PropertyType=1,ProtocolName='Tcp'", ""
I try running it as suggested on the site with
cscript.exe //nologo set_port_property.vbs
and get the error:
set_port_property.vbs(1,1) (null): 0x8004100E
So that's giving me a namespace error and this is where I'm stuck. It doesn't look like anyone else is having issues with this file as I've found it in multiple places, but I'm trying this on a Windows 10 computer with SQL Server 2012 and everything I found was using 2008 and at most Windows 8. There's a Scriptomatic 2.0 tool that may help, but the link on Microsoft's page is broken so I don't know where to go from here.
The error code as you point out is
WBEM_E_INVALID_NAMESPACE (0x8004100E)
The specified namespace did not exist on the server.
Which is pretty self explanatory, basically the namespace being passed is not recognised for whatever reason, usually it's just incorrectly typed but as you have already mentioned others are using this script without issue.
Couple of suggestions
This likely points to the machine, the first thing I would try is running the script on another machine to see if it can be isolated to this machine alone.
You may also want to test the health of the WMI installation using the in-built tools provided in Windows. The wbemtest.exe tool is a great little tool for testing connection to and query WMI respositories.
Stumbled on the Answer
In the process of answering this question think I may have stumbled on the answer.
Tried suggestion 2. myself to test connecting to
root\microsoft\sqlserver\computermanagement
but failed with the same error using wbemtest.exe but found I could connect to
root\microsoft\sqlserver
After a quick google found the MSDN documentation that describes"How to: Access WMI Provider for Configuration Management using WQL" pointed me in the right direction.
You see the namespaces are different for later versions of SQL Server.
SQL Server 2005
root\Microsoft\SqlServer\ComputerManagement
SQL Server 2008 R2
root\Microsoft\SqlServer\ComputerManagement10
SQL Server 2012, SQL Server 2014, SQL Server 2016#
root\Microsoft\SqlServer\ComputerManagement11
# - Possibly subject to change
After connecting to
root\Microsoft\SqlServer\ComputerManagement11
using wbemtest.exe I no longer received the error and was able to browse classes and instances.
With that in mind changing your namespace in the code should fix the issue.
' set TCP/IP port of SQLServer instance 'SQLSERVER_MATRIX'
setProperty "WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement11:ServerNetworkProtocolProperty.InstanceName='SQLSERVER_MATRIX',IPAddressName='IPAll',PropertyName='TcpPort',PropertyType=1,ProtocolName='Tcp'", args(0)
' switch off dynamic ports
setProperty "WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement11:ServerNetworkProtocolProperty.InstanceName='SQLSERVER_MATRIX',IPAddressName='IPAll',PropertyName='TcpDynamicPorts',PropertyType=1,ProtocolName='Tcp'", ""
In fact at the very bottom of that thread on MSDN someone even hints at this but for SQL Server 2008
Goozak posted in MSDN Forums - silent install with fixed tcp port
Date: Wednesday, March 17, 2010 3:13 PM
"know this is an old thread, but since this is the post I found that helped me solve my problem, I just want to add that for SQL Server 2008 Express, you need to use ComputerManagement10 :ServerNetworkProtocolProperty..."
I have strange effects when retrieving columns of type DATE from SQLServer2008 using the Microsoft JDBC-Driver version 3.0 when running under the official Oracle JDK 1.7.0. Host OS is Windows Server 2003.
All Date columns are retrieved as two days in the past with respect to the value actually stored in the column.
I cooked up a minimal code example the test this out (Test table and data):
CREATE TABLE Java7DateTest (
dateColumn DATE
);
INSERT INTO Java7DateTest VALUES('2011-10-10');
Code:
public class Java7SQLDateTest {
public static void main(final String[] argv) {
try {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
Connection connection = DriverManager.getConnection(
"jdbc:sqlserver://192.168.0.1:1433;databaseName=dbNameHere",
"user", "password");
PreparedStatement statement = connection.prepareStatement("SELECT * FROM Java7DateTest");
ResultSet resultSet = statement.executeQuery();
while (resultSet.next()) {
final java.sql.Date date = resultSet.getDate("dateColumn");
final String str = resultSet.getString("dateColumn");
System.out.println(date + " (raw: " + str + ")");
}
resultSet.close();
statement.close();
connection.close();
} catch (final Throwable t) {
throw new RuntimeException(t.getMessage(), t);
}
}
}
Running this code on above configuration prints: "2011-10-08 (raw: 2011-10-08)".
Under JRE 1.6.0_27 it prints: "2011-10-10 (raw: 2011-10-10)"
I could not find anything that seems to relate to my problem with google, so I'm assuming that its either something stupid I overlooked or nobody is using Java7 yet.
Can anybody confirm this problem? What are my alternatives if I still want to use Java7?
Edit: The problem occurs even when running with -Xint, so its not caused by Hotspot bugs.
Edit2: Old drivers (Microsoft 1.28) work properly with JDK1.7.0 (we were using that driver until maybe two years ago, I think).
jTDS also works perfectly fine with the example. I am considering switching to jTDS, but I am reluctant to do so because I have not the faintest idea what the effects on our productive environment may be. Ideally it should just work, but that what I believed when I switched my dev box to Java7, too.
There is one pretty fat database in the production environment, that is too big to create a copy of, for testing (or rather our server has so little disk left). So setting up a test environment for that one app is not straigthforward, I would have to stitch up a shrinked database for that.
Edit3: jTDS has its own set of catches attached. I found a behavioral difference that breaks one of our applications. ResultSet.getObject() returns different object types for SmallInt columns depending on driver (Short vs Integer). Also jTDS does not implement JDBC4 Connection interface, Connect.isValid() is not supported.
Edit4: I noticed last week that MSSQL-JDBC 3.0 refuses to connect to any DB after I updated to JDK1.6.0_29. jTDS it is then... we switched the productive server yesterday (I fixed tow places where the application was relying on peculiarities of the driver), and so far we had have no problems.
Thank you for your feedback. The Microsoft JDBC Driver for SQL Server does not yet support JRE 1.7.
We are aware of the getDate issue between our JDBC driver & JRE 1.7 and we are looking into publishing a hotfix to enable customers to move forward with non-production testing of our driver with JRE 1.7.
We will publish a link to the hotfix on our blog once available.
http://blogs.msdn.com/b/jdbcteam/
The hotfix is now available. http://blogs.msdn.com/b/jdbcteam/archive/2012/01/20/hotfix-available-for-date-issue-when-using-jre-1-7.aspx
Our blog also contains information on the known issues with JRE 1.6u29 & 1.6u30.
Shamitha Reddy
Program Manager - Microsoft JDBC Driver for SQL Server
I don't quite have an answer for you. But, I've recreated your situation as you described. It is the same with the jdbc driver v3.101 and v3.202 and v4.ctp3 when run under jdk1.7. However, the v2 driver from MS gives your expected answer both under jdk1.6 and jdk1.7. If you need a quick fix and can move to an older jdbc driver, that may work for you.
Other thoughts are on how the MS jdbc driver handles dates and conversion of Date objects between SQL Server and the jvm. Since the storage of the date is without a time zone, the interpretation of the Date object by the driver is based on the default time zone for the machine running the jdbc driver. For instance, if you store a smalldate of '2011-10-11 12:00' and retrieve it from a machine with the default time zone set to GMT-7 then the resulting UTC time of the Date object would be '2011-10-11 19:00'. It could be that there is some change in jdk1.7 that impacts this conversion process in the driver resulting in a wild offset. You might experiment with the ResultSet.getDate(column, Calendar) method to see if a Calendar with a specific time zone gets you the result you want or helps make sense of why you are seeing the strange offset in the conversion.
I don't have a SQL Server setup, but I can't reproduce your problem with PostgreSQL 9.0 and MySQL 5.1 on Windows 7 x64 with JDK 1.7.0. So JDK 1.7.0 can be excluded from being suspect. I have the impression that the SQL Server JDBC driver is to blame here. I'd suggest to use the jTDS JDBC driver instead. It has always been praised for its better performance and stability as opposed to the MS-provided SQL Server JDBC driver.
Information and download link for the hotpatch from Microsoft Support can be found here:
http://support.microsoft.com/kb/2652061
I was experiencing the same issue, where the date would be off by two days, and this hotpatch fixed it.
This is also an issue in OpenJDK 1.6.0_20. However, the mssql driver works fine with Suns JRE 1.6.0_16.
I referred this page
http://www.codecapers.com/post/using-ruby-with-sql-server.aspx
my code
DBI.connect('DBI:ADO:Provider=SQLNCLI;Data Source=SQLSERVER001;Integrated Security=True;Initial Catalog=DB001') do | dbh |
# Replace mytable with the name of a table in your database.
dbh.select_all('select top 1000 * from history where type="35" ') do | row |
puts row
end
end
and trying to connect ruby with sql server by Windows authentication . But I got error
Unable to load driver 'ADO' (underlying error: uninitialized constant DBI::DBD::ADO)
Any idea?
Thanks
you don't need TinyTds, my system: ruby 1.9.3, ruby DevKit, sql server 2012, windows 7
install these gems first;
gem install dbi
gem install dbd-odbc
gem install activerecord-sqlserver-adapter
working script below connects, (not sure about the require 'pp')
require 'rubygems'
require 'DBI'
require 'pp'
server = 'XXXXX-LT0XXXX\XXX'
database = 'mydatabase'
conn = DBI.connect("DBI:ODBC:DRIVER={SQL Server};Server=#{server};Database=#{database};Trusted_Connection=yes") #==> sets up the connection
puts conn.connected?
if you pass the sql server instance directly into the connection string with a backslash it error but if passed as a variable it accepts
The page you are refering to is three years old.
Today you should use TinyTds for an easy way accessing
A MS SqlServer ( look at Github for it )
Is there any way I can get my Node.js app to communicate with Microsoft SQL?
I haven't seen any MS SQL drivers out there in the wild?
I'm putting a very simple app together and need to be able to communicate with an existing MS SQL database (otherwise I would have gone with mongoDB or Redis)
The original question is old and now using node-mssql as answered by #Patrik Šimek that wraps Tedious as answered by #Tracker1 is the best way to go.
The Windows/Azure node-sqlserver driver as mentioned in the accepted answer requires you to install a crazy list of prerequisites: Visual C++ 2010, SQL Server Native Client 11.0, python 2.7.x and probably also Windows 7 SDK for 64-bit on your server. You don't want to install all these GB's of software on your Windows Server if you ask me.
You really want to use Tedious. But also use node-mssql to wrap it and make coding a lot easier.
Update August 2014
Both modules are still actively maintained. Issues are responded on quite quickly and efficiently.
Both modules support SQL Server 2000 - 2014
Streaming supported since node-mssql 1.0.1
Update February 2015 - 2.x (stable, npm)
Updated to latest Tedious 1.10
Promises
Pipe request to object stream
Detailed SQL errors
Transaction abort handling
Integrated type checks
CLI
Minor fixes
This is plain Tedious:
var Connection = require('tedious').Connection;
var Request = require('tedious').Request;
var config = {
server: '192.168.1.212',
userName: 'test',
password: 'test'
};
var connection = new Connection(config);
connection.on('connect', function(err) {
executeStatement();
}
);
function executeStatement() {
request = new Request("select 42, 'hello world'", function(err, rowCount) {
if (err) {
console.log(err);
} else {
console.log(rowCount + ' rows');
}
connection.close();
});
request.on('row', function(columns) {
columns.forEach(function(column) {
if (column.value === null) {
console.log('NULL');
} else {
console.log(column.value);
}
});
});
request.on('done', function(rowCount, more) {
console.log(rowCount + ' rows returned');
});
// In SQL Server 2000 you may need: connection.execSqlBatch(request);
connection.execSql(request);
}
Here comes node-mssql which has Tedious as a dependency. Use this!
var sql = require('mssql');
var config = {
server: '192.168.1.212',
user: 'test',
password: 'test'
};
sql.connect(config, function(err) {
var request = new sql.Request();
request.query("select 42, 'hello world'", function(err, recordset) {
console.log(recordset);
});
});
A couple of new node.js SQL server clients have just released recently. I wrote one called node-tds and there is another called tedious
We just released preview drivers for Node.JS for SQL Server connectivity. You can find them here:
http://blogs.msdn.com/b/sqlphp/archive/2012/06/08/introducing-the-microsoft-driver-for-node-js-for-sql-server.aspx
(duplicating my answer from another question).
I would recommend node-mssql, which is a nice wrapper for other connectors, the default being my previous choice (Tedious) bringing a bit nicer of an interface. This is a JavaScript implimentation, with no compilation requirements, meaning you can work in windows and non-windows environments alike.
Another option, if you don't mind bringing in .Net or Mono with a binary bridge would be to use edge.js. Which can be very nice if you want to leverage .Net libraries in node.js
node-tds is abandoned, node-odbc doesn't work with windows, and the MS node-sqlserver driver doesn't seem to work on non-windows (and has some goofy requirements).
There is another module you can use - node-mssql. It uses other TDS modules as drivers and offer easy to use unified interface. It also add extra features and bug fixes.
Extra features:
Unified interface for multiple MSSQL drivers
Connection pooling with Transactions and Prepared statements
Parametrized Stored Procedures for all drivers
Serialization of Geography and Geometry CLR types
Smart JS data type to SQL data type mapper
Support both Promises and standard callbacks
You could maybe use node-tds.js:
An exciting implementation of the TDS protocol for node.js to allow communication with sql server...
USAGE:
var mssql = require('./mssql');
var sqlserver = new mssql.mssql();
sqlserver.connect({'Server':__IP__,'Port':'1433','Database':'','User Id':'','Password':''});
var result = sqlserver.execute("SELECT * FROM wherever;");
TSQLFTW - T-SQL For The WIN(dows) - by Fosco Marotto
https://github.com/gfosco/tsqlftw
It is a C# and ADO .NET managed code solution, with a C++ wrapper that Node.js can import and work with.
If you know .NET you could try WCF Data Services (ADO.NET Data Services); write an WCF app for data access and use odata (REST on steroids) to interact with the database
WCF Data Services: http://msdn.microsoft.com/en-us/data/bb931106
OData: http://www.odata.org/
If you are into SOA and use SQL Server 2005 you could check out the Native XML Web Services for Microsoft SQL Server 2005
http://msdn.microsoft.com/en-us/library/ms345123(v=sql.90).aspx
You could access SQL Server as a web service (HTTP, SOAP)
Microsoft (The Windows Azure Team) just released a node driver for SQL SERVER.
It has no package for npm yert, as far as I know, but it is open sourced. And the accepting community contribution too.
https://github.com/WindowsAzure/node-sqlserver
Introduction blog post here:
http://blogs.msdn.com/b/sqlphp/archive/2012/06/08/introducing-the-microsoft-driver-for-node-js-for-sql-server.aspx
I'd suggest taking a look at Prisma. We just (October 2020) announced preview support for SQL Server.
Prisma is an ORM that puts the emphasis on type-safety and developer experience. Unlike traditional ORMs that typically map tables to classes, Prisma maps queries to types (in TypeScript) and returns plain objects from queries.
To get started with Prisma and SQL Server check out this example and start from scratch guide in the docs.
If you are running on .NET look at entityspaces.js at, we are creating an entire universal ORM for Node.js that will not require a WCF JSON service ... https://github.com/EntitySpaces/entityspaces.js
If you are using MSFT backend technology you could use it now, however, we are creating a universal Node.js ORM and will have more information on that soon
There is an update from Microsoft. Here is a series of blog posts (part 1 and part 2).
Node.js SQL Server drivers seem very immature - there's a mish-mash of different projects with varying dependencies, performance, and levels of completeness, none of which inspire confidence.
I'd propose using edge-sql. This leverages .NET's mature database driver ecosystem, and depends only on .NET (a no-brainer if you are running node on Windows - if not there is Mono, but I have not tried that).
Here is a node example (server.js) using edge-sql (note you need to put your connection string into an environment variable as per edge-sql docs):
var edge = require('edge');
// edge-sql has built in support for T-SQL / MSSQL Server
var getData = edge.func('sql', function () {/*
select top 10 * from sometable
*/
});
getData(null, function (error, result) {
if (error) throw error;
console.log(result);
});
You can also leverage Edge.js with .NET to access other databases, such as Oracle. I have given an example of that approach here.
The status as of May 2016 is as follows.
The official Microsoft SQL Driver for Node, called node-sqlserver, has not been updated for a number of years.
There is a new fork on this called node-sqlserver-v8 that works with Node Versions 0.12.x. and >= 4.1.x. This fork also has pre-compiled binaries for x64 and x86 targets.
The package is available on NPM as msnodesqlv8.
I recommend this package because it is lightweight (has no dependencies) and it is the only one that works with all recent version of SQL Server, including SQL LocalDB.
Now (2016) you can use Sequelize ORM that supports:
MySQL / MariaDB,
PostgreSQL
SQLite
Microsoft SQL Server
It is widely used according to its Github's stars.
that link details only a sql 2000 solution, not sql 2005 nor sql 2008, and also that code only allow sending sql text, and does not allow the execution of stored procedures.
The real solution would be to install node JS on a linux server, or on a virtual linux server on a windows machine, and then go to microsoft web site and download the JDBC java drivers and install those microsoft ms sql java jdbc drivers on either the linux server or linux virtual server.
I am trying to enumerate all SQL Server instances installed on a local machine. I am using SmoApplication.EnumAvailableSqlServers(true). However, only SQL Server Express 2005 instances are shown. Default 2008 instance is not shown at all!
I tried 2 other solutions with SqlServerRegistrations.EnumRegisteredServers() and SqlDataSourceEnumerator.Instance.GetDataSources() but they do not work either.
There is another question regarding this (Can't enumerate SQL Server 2008 Registered Servers with SMO) but it unfortunately has no answer.
Found the solution to your problem here
Solution: Explicitly set the ProviderArchitecture property to the architecture of the target SQL Server.
If you do not explicitly set the ProviderArchitecture property, it will assume that of the running process. If the host process of your application does not match the architecture of the installed version of SQL Server on the target server, the ServerInstances collection will be empty. This is due to the separate x86 and x64 WMI providers and how SQL Server registers instances.
Try
Dim objManagedComputer As New ManagedComputer("target_servername")
objManagedComputer.ConnectionSettings.ProviderArchitecture = ProviderArchitecture.Use64bit
Dim objServerInstance As ServerInstance
For Each objServerInstance In objManagedComputer.ServerInstances
MsgBox(objServerInstance.Name)
Next
Catch ex As Exception
MsgBox(ex.Message)
End Try
Here's another alternative you could try using the ManagedComputer Class (Namespace: Microsoft.SqlServer.Management.Smo.Wmi).
ManagedComputer mc = new ManagedComputer();
foreach (ServerInstance si in mc.ServerInstances)
{
Console.WriteLine(si.Name);
}