I am having an insanely tough time getting Rails to connect to SQL Server on a Mac.
I have set up a DSN using Actual SQL Server drivers: http://www.actualtech.com/ - it works great. I can test it and it seems to be functioning.
However, when I run:
iodbctest "dsn=rails_import2;uid=sa;pwd=mypassword"
The output is:
1: SQLDriverConnect = [Actual][SQL Server] Unable to connect to data source (0) SQLSTATE=S1000
1: ODBC_Connect = [Actual][SQL Server] Unable to connect to data source (0) SQLSTATE=S1000
I have been banging my head against the wall on this for hours. I have tried a lot of things and had it working at one point with FreeTDS +MSSQL (http://blog.opensteam.net/past/2009/1/28/rails_ms_sql_on_mac/), but it broke after a restart.
Any ideas?
So after a few days of mind-numbing experimentation, I've determined that I've somehow hosed my FreeTDS install. Not sure how, but I've basically given up on using the activerecord-sqlserver-adapter gem from my Mac.
The good news? The instructions here at http://odbc-rails.rubyforge.org/ work great. Oh, and you'll also need the activerecord-odbc-adapter gem.
Related
How would I access MS SQL Server with ubuntu 14.04. I tried using freetds I failed to understand the process and It was my first time learning sqlmap. I have tried to read for several hours but in vain. Just give me a clue a way to proceed. I have the IP address of the database but I don't know how I can read it.
DbVisualizer (https://www.dbvis.com) should work for you. Its cross platform, fairly easy to use and can connect to almost any kind of database. You'll need the IP address, port, username and password, just create a new connection and provide the connection details. You then can see the tables and run SQL against them (you're gonnna need to learn SQL if you don't know it).
It would help to know what you are trying to migrate. Im assuming the Ubuntu server is where the data is, but you haven't said what platform you are using or what format you are trying to get the data in. Are you just trying to clone the entire database to your local MySQL process?
I'm trying to connect to an MS SQL database from R (on a Mac) - after fiddling a lot with odbc.ini, odbcinst.ini, and installing freeTDS as described:
sudo port install freetds +mssql +odbc +universal
it now works on the Mac's command line level, but when trying to access it from R using the command:
con <- odbcConnect("myDSN", uid = "myID", pwd = "myPWD")
it just hangs and when forced to stop executing, I get 50+ of the following warnings:
In odbcDriverConnect("DSN=myDSN;UID=myID;PWD=myPWD") :
[RODBC] ERROR: state IM002, code 1421220112, message [iODBC][Driver Manager]Data source
name not found and no default driver specified. Driver could not be loaded
After having tried to make it work for about two days, I'm running out of suggestions. Can anybody help point me to what I am missing?
EDIT: It also works when running R on the virtual Windows machine. How do I get it to work on the Mac?
Did you first configure your MS SQL driver connection? If you have, then you should have a data source called "myDSN" in the OCBC Data Source dialog box.
Here is a great blog which gives step-by-step instructions and screen captures for what you need to do.
When you issue queries in R, R will try to talk to the ODBC data source called "myDSN". That data source knows what database you want (MS SQL) and also what the credentials (username/password) are needed to get access. This is the reason why you must configure the data source.
When I try to install sonarqube database I get some errors and database is not created
ActiveRecord::JDBCError: The driver encountered an unknown error: unable to choose type for timestamp from:
["datetime2", "datetime"]
initialize at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/jdbc/connection.rb:66
initialize at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/jdbc/adapter.rb:31
jdbc_connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/jdbc/connection_methods.rb:6
send at org/jruby/RubyKernel.java:2227
new_connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:223
checkout_new_connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:245
checkout at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:188
loop at org/jruby/RubyKernel.java:1519
checkout at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:184
mon_synchronize at jar:file:/C:/sonarqube/web/WEB-INF/lib/jruby-complete-1.7.9.jar!/META-INF/jruby.home/lib/ruby/1.8/monitor.rb:191
checkout at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:183
connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:98
retrieve_connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_pool.rb:326
retrieve_connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_specification.rb:123
connection at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/connection_adapters/abstract/connection_specification.rb:115
initialize at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:440
up at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:401
migrate at C:/sonarqube/web/WEB-INF/gems/gems/activerecord-2.3.15/lib/active_record/migration.rb:383
upgrade_and_start at C:/sonarqube/web/WEB-INF/config/../lib/database_version.rb:62
automatic_setup at C:/sonarqube/web/WEB-INF/config/../lib/database_version.rb:74
(root) at C:/sonarqube/web/WEB-INF/config/environment.rb:239
load at org/jruby/RubyKernel.java:1094
(root) at file:/C:/sonarqube/web/WEB-INF/lib/jruby-rack-1.1.13.2.jar!/jruby/rack/rails/environment2.rb:1
load_environment at file:/C:/sonarqube/web/WEB-INF/lib/jruby-rack-1.1.13.2.jar!/jruby/rack/rails/environment2.rb:25
load_environment at file:/C:/sonarqube/web/WEB-INF/lib/jruby-rack-1.1.13.2.jar!/jruby/rack/rails_booter.rb:79
i was reading about and looks like database driver is not working alright
Any clues about how can i get this working on SQL Server?
There might be a problem with the locale settings of the database. In my case it helped to set the language for the sonarqube database user to "English". See here.
After a few tries, I changed the SQL driver (sqljdbc4.jar) to one directly from Microsoft, it looks like my previous driver was third party modified.
http://www.microsoft.com/en-us/download/confirmation.aspx?id=21599 this is the original mssql driver form jdbc.
http://www.sezok.de/sonar/sonar.html this guide was helpful too.
after changing driver, everything works OK
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 have written a job server that runs 1 or more jobs concurrently (or simultaneously depending on the number of CPUs on the system). A lot of the jobs created connect to a SQL Server database, perform a query, fetch the results and write the results to a CSV file. For these types of jobs I use pyodbc and Microsoft SQL Server ODBC Driver 1.0 for Linux to connect, run the query, then disconnect.
Each job runs as a separate process using the python multiprocessing module. The job server itself is kicked off as a double forked background process.
This all ran fine until I noticed today that the first SQL Server job ran fine but the second seemed to hang (i.e. look as though it was running forever).
On further investigation I noticed the process for this second job had become zombified so I ran a manual test as follows:
[root#myserver jobserver]# python
Python 2.6.6 (r266:84292, Dec 7 2011, 20:48:22)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import pyodbc
conn = pyodbc.connect('DRIVER={SQL Server Native Client 11.0};SERVER=MY-DATABASE-SERVER;DATABASE=MY-DATABASE;UID=MY-ID;PWD=MY-PASSWORD')
c = conn.cursor()
c.execute('select * from my_table')
<pyodbc.Cursor object at 0x1d373f0>
r = c.fetchall()
len(r)
19012
c.close()
conn.close()
conn = pyodbc.connect('DRIVER={SQL Server Native Client 11.0};SERVER=MY-DATABASE-SERVER;DATABASE=MY-DATABASE;UID=MY-ID;PWD=MY-PASSWORD')
Segmentation fault
So as you can see the first connection to the database works fine but any subsequent attempts to connect fail with a segmentation fault.
I cannot for the life of me figure out why this has started happening or the solution, all worked fine before today and no code has been changed.
Any help on this issue would be much appreciated.
I had a very similar problem and in my case the solution was to upgrade the ODBC driver on the machine I was trying to make the connection from. I'm afraid I don't know much about why that fixed the problem. I suspect something was changed or upgraded on the database server I was trying to connect to.
This answer might be too late for the OP but I wanted to share it anyway since I found this question while I was troubleshooting the problem and was a little discouraged when I didn't see any answers.
I cannot detail the specifics of the underlying mechanics behind this problem. I can however say that the problem was being caused by using the Queue class in python's multiprocessing module. Whether I was implementing this Queue correctly remains unanswered but it appears the queue was not terminating the sub process (and the underlying database connection) properly after each job completed which led to the segmentation faults.
To solve this I implemented my own queuing system which was basically a list of Process objects executed in the order they were put into the list. A loop then made periodic checks on the status of those processes until all had completed. The next batch of jobs would then be retrieved and executed.
I also encounter this problem recently. My config includes unixODBC-2.3.0 plus MS ODBC Driver 1.0 for Linux. After some experiments, we speculate that the problem may arise due to database upgrade (to SQLServer 2008 SP1 in our case), thus triggering some bugs in the MS ODBC driver. The problem also occurs in this thread:
http://social.technet.microsoft.com/Forums/sqlserver/en-US/23fafa84-d333-45ac-8bd0-4b76151e8bcc/sql-server-driver-for-linux-causes-segmentation-fault?forum=sqldataaccess
I also tried upgrade my driver manager to unixODBC-2.3.2 but with no luck. My final solution is using FreeTDS 0.82.6+ with unixODBC-2.3.2. This version of FreeTDS driver goes badly along with unixODBC-2.3.0, for the manager keeps complaining about function non-support of the driver. Everything goes smooth if unixODBC is upgraded.