Bill Witherspoon wrote: >>>> >>> 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
Keep in mind Mixed is SQL + Win. There is no SQL-only, so Win auth will 'always' work. > assume it is passing my domain credentials. I don't know exactly who or what is passing what, and I am not sure what the server does with it :) I got the feeling there was some hand shaking kinda thing going on, where the server knows who you are, but has to actively find out what you currently have rights to, and I am not sure how/where it gets that from. I think it goes like this: you log into your workstation. that tells the workstation OS who you are. you run osql -E and your workstation's OS, the sql servers's OS and the PDC all bounce messages around tell the SQL server what you have access to. The 'bounce' thing is something like: osql asks local os for something. that something gets sent to SQL's OS, which sends it to the PDC, which returns back to SQL's OS some group info, which is handed down to SQL, which now knows what rights you have. big 'I think' around all this. I have never actually gotten it all to work. > >>> 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. lower than that - the python libraries are using free-dts? which is what is imposing the "look for \ in the username" > 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) - What python code works when the server is set to Win only? And what werid things do/dont work? ( like bad user/pw that contain a slash, which I think should work.) > 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. With enough print statements we can figure out what is really going on. Carl K _______________________________________________ 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]
