I assume you masked this line when posting.. have you defined it properly in your prod script?
 Code:
$DBpath = "\\server\...\IT-Inventar.mdb"
These lines
 Code:
$CNstring="Driver={Microsoft Access Driver (*.mdb)}; DBQ=$DBpath"
$CMDtxt = "select * from COMPUTERS where computername = '@WKSTA'"
will no longer work with the NoVarsInStrings and NoMacrosInStrings settings. Seach the core code for any variables or macros inside quotes and change them to the following format:
 Code:
$CNstring="Driver={Microsoft Access Driver (*.mdb)}; DBQ=" + $DBpath
$CMDtxt = "select * from COMPUTERS where computername = '" + @WKSTA +"'"
You will need to search the remaining code for this kind of issue and resolve it. You should not have to check the UDFs as it is a requirement of all public UDFs to properly support these options.

As for debugging, the simplest is something like:
 Code:
XXXXX - @SERROR @CRLF
where the "XXXXX" is something to identify the location in the code. It can be a line number, a function or process name (such as "OpenDbObject"). It's quick and easy to add, but you need to remove or comment them in your production code. I use the fMsg() UDF for my debugging in production scripts.. Something like this:
 Code:
$Rtn = SomeFunction()  ; need to check results..
$Msg = 'Call to SomeFunction() returned ' + $Rtn + '; ' + @SERROR
fMsg($Msg, '', 0, 4)
This will display the result returned as well as the error message produced by the function call. You must define $MSG_LOG_ with the path to the log file/name. With this format, the same message (in $Msg) will be written to the screen and the log file. the empty arg ('') allows a different message to be written to the log, usually with more detail. The third arg will suppress the CRLF, allowing multiple calls to "stack" messages. The fourth arg controls the output - a "4" outputs the mesaage only if the Global $DEBUG variable is non-zero.

Using this method and function, I can sprinkle the code with debug messages, set $DEBUG=1, and get lots of information about the progress of the script. When it's working as desired, I set $DEBUG=0 and the messages go away.

I'm not sure about any of your DB command syntax - it looks not so correct, but I'm not a wiz with DB commands. I'd comment those out and see if the command generates the data you are looking for first. Once you know the data has been correctly gathered, you can focus on writing to the DB. I'd also take a good look at the Database Library instead of manually coding the DB comands, especially if you don't have a strong comfort with OOP and writing connection strings. I found the DBlib collection easy enough for me to write a fairly sophisticated inventory system with a SQL back-end.. \:\) I just had to deal with arrays, field names, and some UDF calls.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D