0

(no responses from my identical post on the MySQL forums & StackOverflow, so I'm hoping to have better luck here)

I'm trying to migrate a MS SQL database for a friend. I do not have physical access to the machine, nor do I have admin access -- just a read/write user.

Using "SQL Server Management Express" in XP, I can easily login using IP/user/password. I can browse tables, run queries. Easy.

When I fire up the Migration toolkit, select MS SQL, and try to connect, I get the following error:

Connecting to source database and retrieve schemata names. Initializing JDBC driver ... Driver class MS SQL JDBC Driver Opening connection ... Connection jdbc:jtds:sqlserver://MYSERVERIP:1433/MYDATABASE;user=MYUSERNAME;password=MYPASSWORD;charset=utf-8;domain= The list of schema names could not be retrieved (error: 0). ReverseEngineeringMssql.getSchemata :Login failed for user 'MYUSERNAME'. Details: net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365) net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781) net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224) net.sourceforge.jtds.jdbc.TdsCore.login(TdsCore.java:599) net.sourceforge.jtds.jdbc.ConnectionJDBC2.(ConnectionJDBC2.java:331) net.sourceforge.jtds.jdbc.ConnectionJDBC3.(ConnectionJDBC3.java:50) net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:178) java.sql.DriverManager.getConnection(Unknown Source) java.sql.DriverManager.getConnection(Unknown Source) com.mysql.grt.modules.ReverseEngineeringGeneric.establishConnection(ReverseEngineeringGeneric.java:141) com.mysql.grt.modules.ReverseEngineeringMssql.getSchemata(ReverseEngineeringMssql.java:99) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) java.lang.reflect.Method.invoke(Unknown Source) com.mysql.grt.Grt.callModuleFunction(Unknown Source)

Any ideas? I've triple-checked the login details, no dice. Am I missing a driver? Is the server setup weird? No idea where to go from here.

Thanks in advance.

2
  • What are you trying to migrate to? Jun 15, 2009 at 21:28
  • MSSQL 8 to MySQL 5
    – jmccartie
    Jun 16, 2009 at 18:22

2 Answers 2

1

Building on squillman's answer - when connecting over TCP/IP, the named instances use different ports, and are most likely using "dynamic ports" (which is the default for SQLEXPRESS). Take a look at the SQL Server 2005 Network Configuration utility to figure out which port it is listening on and connect to that instead of 1433.

9
  • Thanks Matt. I don't have local access to the server, so running the Network Configuration Utility seems to only show me (local). Can I determine the port another way?
    – jmccartie
    Jun 15, 2009 at 22:08
  • I emailed the admin and asked him the port. "1443" he said. :\
    – jmccartie
    Jun 16, 2009 at 18:23
  • Based on the fact that you are getting a login failed message (and not a connection failed) message - there is clearly a SQL Server running on 1443. My guess is you are getting a login failed message because it is not the correct SQL Server instance. Can you run a sql query to print the variable @@servername - that should tell us for sure whether you are connected to a named instance or the base instance. (Also, from there we may be able to concoct a query that pulls a port number from the registry)
    – MattB
    Jun 16, 2009 at 18:54
  • OK - guess that was wrong. This shows that you are connecting to the main instance on the system, which is most likely listening on 1433. Since you are getting login failures - are you connecting using SQL authentication or Windows authentication? And if you are using Windows auth, are you putting the computername/domain into the connection string in Migration Manager?
    – MattB
    Jun 16, 2009 at 19:09
  • Using SQL auth. (thanks for your continued help, Matt)
    – jmccartie
    Jun 16, 2009 at 19:20
1

You mention that you're using SQL Server Management Studio Express, is the server also SQL Server Express?

If so, then from the stack trace in your question it looks like the JDBC driver is attempting to connect to your source server by IP with no SQL instance name:

Connection jdbc:jtds:sqlserver://MYSERVERIP:1433/MYDATABASE;user=MYUSERNAME;password=MYPASSWORD;charset=utf-8;domain=

which would be a default SQL Server instance. By default, SQL Express installs a named instance called SQLEXPRESS, so my guess is that the migration toolkit is looking for a non-existent instance of SQL. I'm not familiar with the migration toolkit, but if I'm right about your SQL instance name you should make sure it's trying to connect to your source SQL instance with SERVERNAME\SQLEXPRESS (where SERVERNAME is the hostname of your SQL server).

EDIT:

Ok, now that we've apparently ruled out an incorrect instance issue... I would say go and get the newest SQL Server jdbc driver from Microsoft and try using it with the toolkit. I've had problems in the past connecting different apps via JDBC to SQL Server using other drivers. I'm not sure how to get the toolkit to use a different driver off the top of my head, but I'll help look for posts / instructions on how to do so.

5
  • SQL Server 8.0.2039 Where do I find the instance name? The server is not local.
    – jmccartie
    Jun 15, 2009 at 22:06
  • Connect in Mgmt Studio and run this from a new query window: SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition'). That'll tell you if it's Express or not.
    – squillman
    Jun 16, 2009 at 1:00
  • || 8.00.2039|SP4|Enterprise Edition (1 row(s) affected)
    – jmccartie
    Jun 16, 2009 at 18:21
  • Hmm. Ok blows that theory...
    – squillman
    Jun 16, 2009 at 21:41
  • Thanks Squillman. I downloaded the SQL JDBC driver from MSFT. I then searched all over for how to swap out the drivers - couldn't find anything. I tried simply removing the jtds.jar and renaming/replacing it with the MSFT driver...no dice. Thank you for your continued help -- it's much appreciated.
    – jmccartie
    Jun 16, 2009 at 23:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .