Issue with Table Editor

[dba0522]

I upgrade from 5.2.5 to 5.3. The table and column information is not fully populating and I can't edit anything like I did on 5.2.5

See Screen Shots

[dba0522]

Reverted Back to 5.2.5 and it is working properly again.

[serge-rider]

I guess you are using jTDS driver.
In 5.3 we no longer support jTDS driver for the new SQL Server extension.

If you need all new features - please migrate your connection to the new SQL Server / Microsoft driver.
You can use main menu Database->Migrate Connection(s) for that.

[dba0522]

We have some people use MAC's that are not integrated with AD. The jTDS allows you to configure the driver to use NTLM so you can authenticate to SQL Server. So, far, I do not see an option with Microsoft Driver to do something similar.

If you know of any how-to's on resolving this, it would be appreciated.

Still doing some research as well.

Thanks

[serge-rider]

I didn't test that however there should be the way in the new version of driver.
Did you try to set authenticationScheme and serverSpn driver props?
https://docs.microsoft.com/en-us/sql/connect/jdbc/setting-the-connection-properties?view=sql-server-2017

[dba0522]

I tried a few things with no luck... You would think simple connectivity would be, well, simple. :)

I will do some more research. Back to 5.2.5 for now.

Thanks for the response...

[serge-rider]

Potentially we can add jTDS driver back. The problem is that it acts quite differently than Microsoft driver in some aspects (e.g. CLOB/BLOB handling) and it is not that easy to support both drivers.

But we'll do this if no other solution will be found.

[dba0522]

Ok, I have not found a solution for this until 5.3.4... (probably in 5.3.3 when you released it)

Here is how I got a mac, not on a domain, to log into a sql server using AD credentials

Use Authentication Method: Kerberos

Now, how you define the username is critical...

using a user name of: domain\user name did not work
using a user name of: username@addomain . did not work (ad domain Lower Case)
using a user name of: username@ADDOMAIN ### WORKED (ad domain ALL Upper Case)

This behaves like a linux system when registering it to a domain, the domain represents the REALM, which must be UPPER CASE.

Now, why don't you allow saving of username and password? I have to type it in every time.

I got around this by selecting CUSTOM. Entering my user, password and clicking save password. I then selected KERBEROS and it now auto logs in with username and password because when I selected KERBEROS it did not clear it.

Please allow the user name and password to be saved...

[dba0522]

Also, why does SQL Server Entries not support instance names?

Example: DBSERVER\INT

If I add in driver properties in breaks the login...

We are so close... Luckily, I only have 10% that use instances...

[dba0522]

here is where I am at with testing.

• Create new Connection with MS Driver
• Enter Server Name
• Uncheck . Save Password
• Uncheck Trust Server Certificates
• Select Kerberos . (Can't enter or save username and password on initial creation)
• Click OK to Save
• Now click on the new connection you just created
• When it prompts for credentials, enter the user and password.
  - NOTE: If you want to save you password, click the check box.
  - NOTE: The user@DOMAIN must have the DOMAIN capital.
• You should now be logged in and password saved.

Now for the BUGS, I think:

• You can't save the username and password once Kerberos is selected during initial setup. Should be able to...
• If you change the port from the default 1433 to something else, login's fail. Fails both when setting on the main connection setup page and when trying to do with the driver properties
• Can't get the instance to work either when setting in the driver properties page.

[dba0522]

Sorry for the blog...

The easiest way I have found is:

On the mac do a: kinit user@DOMAIN
Create the connection with MS sQL
Enter Server Name
Select Kerberos
Click OK

It will now prompt for a username and password, but just click ok and it uses the token created by KINIT

NOTE: SQL Instances and ports other then 1433 still cause logins to fail