rails-sqlserver / tiny_tds

TinyTDS - Simple and fast FreeTDS bindings for Ruby using DB-Library.
Other
606 stars 190 forks source link

Incorrect syntax near 'OFFSET' when connecting to SQL Server 2019 #482

Closed jeremysenn closed 3 years ago

jeremysenn commented 3 years ago

Environment

Operating System

PRETTY_NAME="Debian GNU/Linux 10 (buster)" 
NAME="Debian GNU/Linux" 
VERSION_ID="10" 
VERSION="10 (buster)" 
VERSION_CODENAME=buster ID=debian 
HOME_URL="https://www.debian.org/" 
SUPPORT_URL="https://www.debian.org/support" 
BUG_REPORT_URL="https://bugs.debian.org/" 

TinyTDS Version and Information

tiny_tds: 2.1.2
activerecord-sqlserver-adapter: 6.0.0

FreeTDS Version

# tsql -C

Version: freetds v1.00.104              
freetds.conf directory: /etc/freetds      
MS db-lib source compatibility: no         
Sybase binary compatibility: yes                       
Thread safety: yes                      
iconv library: yes                         
TDS version: 4.2                               
iODBC: no                            
unixodbc: yes               
SSPI "trusted" logins: no                            
Kerberos: yes                             
OpenSSL: no                              
GnuTLS: yes                                
MARS: no

Description

We recently upgraded to SQL Server 2019, and now have some problems properly connecting to the database.

The first issue that we noticed was the "Incorrect syntax near 'OFFSET'" when doing any searches of the database in Ruby (e.g. Image.find(1) ).

Upon further investigation we found the following:

Image.columns_hash => {}

However, we have no problem listing columns via the console when using the tds client directly:

results = client.execute("SELECT * FROM INFORMATION_SCHEMA.COL MNS WHERE TABLE_NAME = N'images'")

From the client in the console the compatibility level is correct:

{"compatability_level" => 150}

However, client.tds_version_info gives:

"DBTDS_7_3 - Microsoft SQL Server 2008"

Any help would be greatly appreciated!

jeremysenn commented 3 years ago

We changed the default schema for the user to dbo, which seems to have solved the issue at this point.