>>> >>> >> Both of osql lines did work. >> >> c:\>osql -S 192.168.51.26 -E
This line works regardless of server setting (WinAuth only or Mixed). I assume it is passing my domain credentials. >> >> returns the 1> prompt like you described. > > yay! > >> c:\>osql -S 192.168.51.26 -U plant_user -P emseal01 >> >> also returns the 1> prompt. > > Is the server currently set to Win or Mixed? In order for this to work the server has to be set to Mixed. It fails if set to Win Auth only. > >> I assume that fact that the first works means that Win Auth works, and >> that the second works means that SQL Auth works. > > While we are at it, try with just c:\>osql -S 192.168.51.26 > >> There seems to be some kind of inconsistency here, but I can't seem to >> put my finger on it. >> > > I can: when using Win Auth, osql does not require a user/pw when connecting > but > that other stuff I posted does. the low level thing that looks for the \ > (or > /) in the username may not even be doing the win auth thing to spec, but the > docs kinda implied it did. and then python and dabo all rely on it, so they > have the same requirements. > To my way of thinking the inconsistency lies in one of the python libraries. It appears that Win Auth works (using ODBC, or osql.exe), and it appears that SQL Auth works (using osql.exe, or stand-alone python code that import pymssql) - but neither Win Auth or Sql Auth work through the dabo connection dialog. This despite the fact that I've confirmed that it appears that dabo is passing the same parameters which work (for Sql Auth at least) in the hand coded sample. Very strange. Bill. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
