Replies

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
</script>
<table border=1 bgcolor="">
 <tr>
 <csp:while counter=queryCol condition="(queryCol<query.GetColumnCount())">
  <th align=left><b>#(query.GetColumnHeader(queryCol))#</b></th>
 </csp:while>
 </tr>

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

 

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.

Success!!!

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.


Thanks

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:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

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.

When you are using the Text Categorization, you need to have a piece of meta data that is used to group the text into different categories. "Gender", or "Month" or, "Diagnosis Code", etc.  Then each record has to have one of these values associated with it, so the learning process can determine what concepts/terms go with which category.

You will get the "category 1 covers the whole data" error, if you don't have a meta field either defined, or correctly populated. Without some level of variability in the "category" identified meta data field, the machine learning doesn't have reference point to sort out your text records.

Make sure that you both HAVE a Meta-Data element defined, and that there are differing values within the record set that you are using to create the categorizations.

Just out of curiosity, which part of HealthShare are you running these queries? Are you looking on the Access Gateway, Edge Gateway, Registry?

They all use the same message structure, but in different parts of the "request/response" cycle. The "facing the outside world" context is the Access Gateway, the rest are more "internal to Information Exchange" propagating of the request and motivating the various parts to gather the response, so it's quite likely that (as Justin mentioned) there can be replications of the message content into "new message" records that are NOT actual "new requests".

When you look directly at the SQL table outside of the context of the complete message trace (i.e. a "Session") it should be expected that you will see what appears to be exactly the same content in multiple messages in the table.