Yup, that smells already ...
I made a UDF in the past that I know was created while on Windows 7 and it used DefaultNamingContext. You might give it a shot and see if you get the same results.
Tried the UDF - same result, fails at the ".get" statement.
But ... to make things more confusing: After lots of testing with different KIX versions, I found out that the source location of KIX32.EXE makes the difference !
As you can imagine, the test code was not called in a login script, but interactively.
So, whenever kix32.exe is stored on the local HDD, it works fine !
Also, calling KIX32 from the netlogon share works. Only when calling it from my development (which I did all the time) share, it fails with the explained symptoms.
Btw, all this testing and the issues explained only refers to the code pasted above !
For this tests, I have no other KIX script around this, and always called it manually from the command prompt (aka dos-box) like this:
\\server1\share$\dir\kix32.exe c:\temp\ADOquery.kix
or
c:\temp\kix32.exe c:\temp\ADOquery.kix
or
\\domain\netlogon\kix32.exe c:\temp\ADOquery.kix
The first two calls work fine, the last executes the KIX, but drops out when reaching the .GET statement.
Do you have _any_ idea what difference the location of KIX32.EXE makes for running a KIX script ??
Andy
