I am just trying to get the tutorial working. I got the JDBC connection set up for my music SQL Server database in the Studio app. I am sure of that, as the autogenerated mapping is showing the correct tables. But I can't get the app to accept the provided mapping file. I can clearly see that the syntax of the autogenerated mapping is different from that of the provided one, thus it fails at the :Album token in row 4. If there are multiple formats why isn't there any option in the app to select the correct one?
On the other hand, I couldn't get it working with the command line approach either. I have a named SQl server instance. They listen on dynamic ports, not 1433. The actual port is published by the SqlServer Browser, which always listens on 1434. When adding the database connection with the app, this was no issue. As soon the browser service was up and running, the app could establish connection. But not the command line: The TCP/IP connection to the host DESKTOP-AENLEVI\SQLDEV, port 1433 has failed.... Yes, indeed, I am not specifying any port in the URL, because there is no fixed port to specify.
Thus neither approach worked for me. I managed to get the command line version working by temporarily forcing the SQL server instance to use a fixed port and then going back to dynamic.
But either should the command line version be able to use the named instance as the app version can, or the app version should be able to parse the same mapping file (too) as the command line version can. It is very confusing that they work differenctly.
Thanks for reporting this Zoltán. The tutorial uses an older mappings syntax which has been replaced with a newer syntax called SMS2. Stardog Studio currently only allows editing mappings using the newer syntax.
Regarding the SQL Server connection, I'm not familiar with this listener setup. Is it possible to connect to the server through the browser using the JDBC driver? Can you share any docs on the setup of this browser?
I got the differences, but then the mapping from the tutorial should be available on github in both formats.
Yes, when establishing the connection directly from Stardog Studio the JDBC URL to the named instance worked without specifying any port. Thus it correctly turned to the SQL Server Browser to get the actual port of the server instance. The Browser is part of the SQL Server installation, it is a service that is turned off by default in most cases. But it is needed only when you use named instances. If would install SQL Server as "default instance", it is mapped by default to port 1433 as you would expect. This is because there can be multiple named instances of SQL Server running on the same machine, because it is more than an RDBMS, it is an application server, thus instances are a means of application isolation. Anyway, all official SQL server connectors can take this into account, as the name of the instance (if named) is part of the connection string (URL). The code that is called by Stardog Studio when adding the connection works, the same URL however did not work with the CLI.
Here is the link to the official SQL Server JDBC URL documentation. As you will see, the name of the instance is optional. If there is no instance name specified, then the default instance is assumed with the default port, if no other port is specified. However, if there is a name specified, you can't assume any port. There can be a fixed one for a named instance too, but most likely there isn't and the SQL Server Browser will tell you the port number to connect to.
I am no Java developer, thus I have no idea what can be the difference on code level between the CLI and the code inside the service.
We're working to update to the tutorials to use the new mapping syntax supported natively in Stardog Studio. Thanks for bringing it up.
And thanks for sharing this information about SQL Server. I was not aware of the browser service. This will be helpful to know about when debugging future connection issues.
Glad it's working. Let us know if you have any other questions or issues.