1. If you are using KGen, it should report every variable that has not been declared. Look at the .RPT file that is created in the same folder where you built your script. It contains all the warnings. Post it if you need clarification of the contents.

2. This was explained above. The data query replaces the "|" delimited string with an array - you don't need to do this again. The code example provided for the display/data write can be used as-is for display and modified to write $Nic to the DB in the DB Write section. If you want a simple DB write logic, forget the For/Next and simply write a comma-delimited string to the DB record with Join($aData, ','). Put that in the command to write to the database as the Value.

3. I don't understand how you got
 Code:
For each $aData[$P] in split (($aData[$P]),"|")
Next
out of the example I posted:
 Code:
'CD Keys: ' ?
For Each $Key in $aData
  $Key ?
Next
Your code isn't valid. If you are doing a "For Each", you need two variables. One is the array of data and the other is the variable used to enumerate the array. You can't use the same var for both. For example:
 Code:
$Array = GetArray() ; function returns an array of values
For Each $Value in $Array  ; walk the array, assigning each element to "$Value" one at a time
  $Value ? ; do something with the value
Next
What you put in the For Each/Next loop will depend on your requirement. You might use this TWICE in your code, once in the debug section that displays the values, and again in the section that writes the data to the DB.

..................

I'll be honest and tell you you're falling into one of the most common development problems that young coders make - you're trying to work on a large project all at once.

When something doesn't work and can't be fixed in a few minutes, create a test script and include just what's needed for the part giving you grief - var declarations & initializations, data collection, and the data processing. So, for your NIC and CDKey issues, create two small scripts, one for each process. The code should init the vars you use, call the function to get the NIC or CDKey data, and then enumerate the results to display the values. This lets you focus on JUST what is needed for this to work with no other distractions. Then you can move the working code from the small scripts into the larger script.

In fact, this is where KGen excels..
Create Project.TXT and use it only to define the variables
Create a DataCollect.UDF file, and define ONE data collection set of function calls, maybe some WMI values.
Create a DataDisplay.UDF file, and in an If $DEBUG / EndIf block, display the value(s)collected above.
Create a DatabaseWrite.UDF file, and in an If Not $DEBUG / EndIf block, write the value(s) to the database.

Run KGen to combine these 4 files and all the required external functions. Verify that the data collection, display, and DB-Write functions work. Having a small number of similar data elements to work with will make debugging easier.

When this is working, and you've worked out any display and DB-Write issues, update the 3 UDF files to add another collect/display/write block. Focus on getting this to work, then repeat as necessary until all of the data is working. Not only does this help focus on developing specific blocks, it keeps the blocks in sequence in the collect, display, and DB-Write sections. This makes further debugging much easier.

I use KGen in this manner for all my larger projects. I actually have broken one project into many separate files:
- project.txt - the var init code
- Coll_01_xxx.UDF to Coll_07_xxx.UDF - separate files for each set of data collections
- Proc_01_xxx.UDF to Proc_07_xxx.UDF - separate files for each set of data processing
- ZZ_CommonFuncs.UDF - a set of project specific functions
KGen assembles these in alphabetical order, so I name them so all data collections come first, then all the data processing, followed by common functions and then public library functions. the "xxx" is a short description of the data being collected or processed.

Also, you would not believe the number of small script segments I have in the "Misc" folder of my dev library that have been created to test/validate the logic of some process. I keep them because I often revisit the logic for future projects, or when I find a potentially better way to do something. It's kind of like the "morgue" that artists use, just for code snippets. ;\)

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