Vince,

though Stefan is completely correct, I try to explain it in other words:

• UDT uses a serialized storage format, i.e. each field value is stored in a table as single record in table UserDefinedData, containing the tuple (rowId, columnId, fieldValue). This is suboptimal on heavy populated tables but preferable on sporadically populated tables and required an additional transformation, when read into memory
• main advantage of serialization is flexibility: multiple different tables can be stored in 3 tables:
  • UserdefinedFields containing column definition and specification
  • UserDefinedRows containing rowID
  • UserDefinedData as described before
• no tables need to be created or modified, when a module is setup or need to be deleted on module deletion
• data integrity is nearly completely delegated to the frontend

As a conclusion: UDT storage format has advantages and disadvantages, but for the purpose of this module, it is preferable.

Regarding you requirements: Category 1 and 2 are implemented, 3 is still on our schedule for a later release. 
Your assesment a) is correct, b) not - but I can proove, that all your requirements can be fulfilled - please contact me offline at leupold (at) gamma-concept (dot) de.

i am using the UDT for processing and report stats on 8 to 10 thousand drug results a month for a company. once fixed the join on the tables and  set up a schedule reindex of the db  for index fragmentation ( it was getting 60% fragged in a week). it is running really good right now. I  am moving the conversion of the table to the SQL db from the module to improve speed again and allow me to start using  SQL reports for statistics.  This is really a neat module when working correctly and lends itself to many different types of dynamic appications in the portal engine.

richard