Append values returned from a sub into a table

[munkee]

I am using a sub routine which returns values in the following way (it is just looking at the ldb of the access file):

W7BC-P1595
Admin
True
Null

If there are two users in the back end it will show:

W7BC-P1595
Admin
True
Null
W7BC-P1534
Admin
True
Null

Each line of the above is looped through so each is created in turn, the above is from my immediate window.

I want to place these values in to a table set up as follows with sql:

CREATE TABLE tblLDBViewer (Computer TEXT(255), Username TEXT(255), Connected? TEXT(255), Suspect? TEXT(255))

How would I get my data to be sent to this table in the correct order?

So W7BC-P1595 goes in to computername, Admin in username, True in Connected? and a Null in Suspect. Then, if there are two people in the database the code will return a new line for the second person.

I assume this could be done with some form of loop but I cant figure it out.

This is the current loop I have:

With rst    'fills Recordset (rst) with User List data
  Do Until .EOF
    intUser = intUser + 1
      For Each fld In .Fields
        varValue = fld.Value
          'Some of the return values are Null-Terminated Strings, if
          'so strip them off
          
          If InStr(varValue, vbNullChar) > 0 Then
            varValue = Left(varValue, InStr(varValue, vbNullChar) - 1)
          End If
          Debug.Print varValue
          strUser = strUser & ";" & varValue
      
      Next
        .MoveNext
  Loop
End With

The varvalue debug.print is the list from above. I was originally going to have this in a listbox but I need to be doing a bit more with the data so a temporary table will be needed.

[NeoPa]

Subroutines don't return values. Procedures that can, are called functions (or methods for within a class).

Can we see the code of your function. How that works will determine how the calling code would be able to process the data.

Have a look at Access VBA DAO Recordset Loop Using Two Recordsets for some basic code that includes the sort of thing you will need.

Lastly, I would suggest the table would need to be a permanent table, but would be cleared and repopulated as and when required.