That's great! I'm glad to hear it.
Thank you very much for providing patches for this issue. -- Sent from my Android phone Francisco Figueiredo Jr. Npgsql lead developer fxjr.blogspot.com twitter.com/franciscojunior Em 10/03/2011 09:01, "Ahmed Shinwari" <ahmed.shinw...@gmail.com> escreveu: > Hi Fransisco, > > I tested the latest Npgsql driver (2.0.12.0), the issue has been fixed. I > was able to connect Npgsql test application from my Windows XP client > machine with the PostgreSQL server running on Windows 2003 Server. > > Thank you for applying the patch. > > > On Thu, Feb 24, 2011 at 3:37 PM, Ahmed Shinwari <ahmed.shinw...@gmail.com >wrote: > >> >> >> On Sat, Feb 19, 2011 at 11:31 PM, Brar Piening <b...@gmx.de> wrote: >> >>> On Thu, 17 Feb 2011 07:58:46 -0800 (PST), Ahmed < ahmed.shinw...@gmail.com> >>> wrote: >>> >>>> I tried changing that one line to use UTF-8 encoder, but the password >>>> packet >>>> didn't get fixed. It works smoothly if kept in byte array instead of >>>> string. >>>> >>> Yes, as SSPI uses binary bytes we have to avoid to convert them to >>> characters and back to bytes during message generation. >>> >>> While "char *buffer" in C can serve as both a string and a buffer of >>> binary bytes, we have "byte[]" as binary buffer and "string" as string in >>> c#. >>> This is the reason why we need to use byte[] in all places where libpq >>> uses char* without really caring whether there is a string inside or some >>> opaque bytes. >>> >>> >>> I think changing the AuthenticationSSPI case to use context.Host may >>>> break >>>> the cases Brar's mentioned. >>>> >>> If this isn't necessary to fix the problem we should probably get some >>> more instight to what really happens here before fixing one end and breaking >>> the other. >>> >> I agree. >> >> >> For now, Francisco may check in that part which fixes the bug due to >> encoding. And, address the later issue after further investigation. >> >> >> >>> >>> Regards, >>> >>> Brar >>> >> >>
