Hello Dhaval,

I don't believe that there is a clean way to access the property you are looking for, though you may be able to finagle the data you need in SQL with the $list function.

On the first array level (Employee), Cache projects the property as a table, allowing for easy SQL access.  However, because Employee is not Persistent, it cannot project its address array property as a table.  Any SQL access will have to deal with the $listbuild that the second level array is stored as.

If possible, I would make Employee a stand alone table, maybe as a Relationship rather than an array.  

I recall seeing this work before, but I believe it took a good amount of extra javascript work to get the ZEN drag and drop mechanisms (see doc) working nicely with the cells of tablePane. 

In general, "list of ___" properties don't play well with SQL.   Looks like we just present the list as a string.

Using the Generate CREATE TABLE statement feature of WinSQL for Sample.Person gives:

    FavoriteColors VARCHAR(4096)

Hello Mikhail, Good question!

I think of block count as a rough estimate of the disk size of a table or index (an "SQLmap").  The SQL optimizer uses this to get an estimate of how much disk I/O could be involved in scanning that map.  Block count mostly matters in proportion to other block counts (similar to ExtentSize).  

I am not certain how to interpret 2K reference in the documentation, perhaps someone else will chime in - my guess is that the "units" don't matter, so the original 2K block size is still used as a base unit for measuring the disk size of a storage map.

Block Count can be extremely important for tables that have child tables, or that otherwise share a storage global with other classes. The row count might be relatively small, but because the global nodes are spaced out, more disk I/O is required.  With the block count taken into consideration, the SQL optimizer may be pushed toward an index or different starting table.