Thanks, this looks like it will function for my needs.

The account I'm using has %All (and doesn't have any problems with regular .cls class files) so I'm not sure that this is my issue.

I found that creating a "Data Container" by extending the %DeepSee.DataConnector class allowed me to make an SQL based "source" where I could then create the dynamic filtering I wanted within the SQL of the container, and the balance of the IRIS Business Intelligence machinery would work just fine.

Hello -

There are multiple means of rendering a table in a "grid", from a simple html table populated with an SQL query, to ZEN "Grid" object

For the html table, the following code would give you a table from the SQL query

<script language=SQL name="query">
SELECT * FROM User.DataTable
<table border=1 bgcolor="">
 <csp:while counter=queryCol condition="(queryCol<query.GetColumnCount())">
  <th align=left><b>#(query.GetColumnHeader(queryCol))#</b></th>

 <csp:while counter=queryRow condition=query.Next()>
 <tr class='#($S(queryRow#2:"DarkRow",1:"LightRow"))#'>
  <csp:while counter=queryCol condition="(queryCol<query.GetColumnCount())">


For the ZEN example, take a look at your "local" sample page:  <localhost>/csp/samples/ZENTest.DynaGridTest.cls

In answer to the "Why?" questions...

Assume you have a generic "Person" record, and now you want to treat this "Person" as a "Doctor" record where Doctor is an Extension of Person. When the Person record was created, it was not known that this represented person was a going to be doctor record at some point in the future. The person record was created, properties set to values, and saved, linked referenced (i.e. "used" as a Person record). Now at some point later, there is a need to make a "Doctor" record out of this "Person" record. Since anything you could do with/to a Person record can be done with a Doctor record and Doctor only adds functionality (and possibly overriding methods), creating a "new" Doctor record and then replicating data values will not update any references to the "Person" record (and may not even be identifiable from just the Person record to begin with), but morphing that instance of a Person into an instance of a Doctor will preserve all of the references that might exist while enabling the new properties and methods of a Doctor.


I created a callable ZenMethod function that allows me to pass in the table component ID, the SQL Table name and the Row ID, that will jump the table to the correct page and row to match the ID passed in.

Method jumpTable(componentID as %String, tableName As %String, id As %String, pageSize As %Integer) [ ZenMethod ]
  set SQLtxt = "SELECT *, CEILING(%vid/"_pageSize_") PageNum, {fn MOD(%vid,"_pageSize_")} RelRowId FROM ( SELECT ID FROM "_tableName_") WHERE ID = "_id
  set sql1 = ##class(%ResultSet).%New()
  do sql1.Prepare(SQLtxt)
  do sql1.Execute()
  while sql1.Next() {
    set page = sql1.Get("PageNum")
    set row = sql1.Get("RelRowId")
  set Table = %page.%GetComponentById(componentID)
  set Table.selectedIndex = (row-1)
  set Table.currPage = page

This then can be used for any table on any zen page.


My problem is that my table (which *is* filled via an SQL) can have multiple pages of "displayed sub-sets" (i.e. the Page Size of the table, controlled by the Table Navigator), and when I launch the page directly with an instance ID passed by URL value, I can load the form, but I don't see anyway to figure out which page and which row to "jump to" and "select" programmatically. (my use case is relatively simple, as I don't have any client side filters or sorting that is done, just a "result set being displayed"

Hi Scott -

Part of this depends on "how" (from what context) did you create your "export"

Assuming that you mean that you created an "export" from the System Management Portal:

Then review the documentation that can be found:

which will talk about the "Deployment" process for an "exported production"

Assuming that you are talking about an "export" from Studio, then the specifics of how a Business Operation is configured will be in the class definition of the Production Class (along with the actually configured Business Service/Operation class definitions (if they aren't standard InterSystems provided classes : i.e. If you have created your own FTP Operation class as opposed to using the FTP operation class InterSystems ships with the product)):

Then in this case you are looking at a more manual code promotion process, which involves importing from within Studio and recompiling things. This methodology is can work, but has a lot more moving parts (and therefor more "gotcha's" to look out for)

This may well have been the issue, "File full" tripped complete journaling off and subsequent save fail "undo" was failing to rollback. This makes sense. Thanks

This of course run smack up against "what is being required" of system admins by security departments compared to ACTUAL security. Never confuse useful with required.

Knowing how to force the "less secure, but mandated" patterns is really what my question was about.