I tend to use %INLIST $ListFromString(?) in cases like this. (Assuming that the list is something like IDs that wouldn't contain commas.)

So, in your example:

<tablePane  width="25%" id="testTable" sql="SELECT Id from Tracking_Data.Person WHERE Id %INLIST $ListFromString(?)" showQuery="true">
<parameter/>
</tablePane>
<button caption="Test" onclick="zenThis.composite.testTestTable();"/>

ClientMethod testTestTable() [ Language = javascript ]
{
  var table = zenThis.composite.getChildById("testTable");
  table.setProperty('parameters', 1, '1,2');
}

This should definitely work. Are you setting the showTabBar property to true for the nested tabGroup? If not, that might explain why nothing is showing up.

I did a project similar to this using %Net.POP3 a few years back (internal ref: ISCX2452), but it's part of a much larger application, so the exact code probably would not be very useful.
The general pattern for using %Net.POP3 is:

Add your own status-checking, try/catch, etc. One important caution: always be careful to clean up the connection when you're done, with either QuitAndRollback or QuitAndCommit. This might be the cause of the error you noted in your last comment - an open connection could be left over from before, blocking additional connections. I think terminating the process will fix this. (I remember this causing all sorts of trouble/confusion on my old project.)

As a side note: if your application/use case is running on Ensemble, EnsLib.EMail.InboundAdapter will do a lot of the hard work for you. See for reference: http://docs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls?K…

This adapter will delete successfully-processed e-mails. From a "syncing" perspective this keeps things simple. If you don't want the messages deleted, a simple workaround might be to subclass EnsLib.EMail.InboundAdapter and %Net.POP3, override DeleteMessage to make it a no-op in the %Net.POP3 subclass, and override the adapter's MailServer property to use your %Net.POP3 subclass. (This would be a bit less messy than overriding OnTask.)

I think SYS.Database (in %SYS), rather than Config.Databases, can accomplish what you want. Particularly, you can open an object representing a database, call its Delete() method, and then call %Save() on it. That seems to have the same effect you're looking for.

Here's a sample class (Demo.Recreate):

Include %occInclude

Class Demo.Recreate

{

ClassMethod Run(pDBDirectory As %String)

{

    new $Namespace

    zn "%SYS"

    try {    

        //Get the database

        set tDB = ##class(SYS.Database).%OpenId(pDBDirectory)

        If '$IsObject(tDB) {

            $$$ThrowStatus($$$ERROR($$$GeneralError,"Database "_pDBDirectory_" not found."))

        }

        

        write !,"Properties of database:",!

        zw tDB

        

        write !

        

        //For demonstration purposes: show contents of a global in that DB

        for i=1:1:10 {

            set ^["^^"_pDBDirectory]demo(i) = i

        }

        write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!

        zw ^["^^"_pDBDirectory]demo

        

        write !

        

        write "Deleting database..."

        $$$THROWONERROR(tSC,tDB.Delete())

        write " done.",!

        write "Recreating database..."

        $$$THROWONERROR(tSC,tDB.%Save())

        write " done.",!

        

        write !

        

        write !,"Properties of database:",!

        zw tDB

        

        write !

        

        //For demonstration purposes: show that contents of global in that DB are gone

        write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!

        zw ^["^^"_pDBDirectory]demo

        

        zw tDB

    } catch anyException {

        write anyException.DisplayString(),!

    }

}

}

Rather than projecting the property as a table, one option would be to write a custom class query that $orders over the index global, make the column name "KEYS", and make it an [SqlProc]. The SQL would then look like:

SELECT DISTINCT KEYS FROM MyClass_CustomQueryName()

It would be nice if there was a generic solution. My first thought was to add this query to an index class (i.e., one that extends %Library.CacheIndex) and generate <query>Fetch/Execute/Close methods for indices that on property(KEYS), but it seems that queries aren't supported as index members. The <indexName><query>Fetch/Execute/Close methods are generated in the persistent class, but there's no actual class query visible from SQL. Maybe %Library.FunctionalIndex would work if you don't mind reinventing the standard bitmap insert/update/delete, but I suspect that you'd end up losing FOR SOME %ELEMENT in this approach, and would need to replace it with %FIND.

I'll send you what I came up with while investigating - maybe it will provide food for thought.