Iterating through table instead of using switch statement

Nate,

Why not put the value you are looking for in the ‘IN’ column and what you want to do when it matches in the ‘OUT’ column.

Like this:

IN                                             OUT

STAPHYLOCOCCUSAUREUS         DE-14117|Staphylococcal disease, invasive|700043|YES

CLOSTRIDIUMBOTULINUM           L-14118|Botulism|700002|YES

Then simply match $OBXsave to the IN column with hcitbllookup and do your work with the OUT Column.

Nate,

The other option that you have is to load the table into an inboundList and outboundList.  You can then utilize an ‘lsearch’ to find your value in the inboundList and use the returned index to find the element in the outboundList.  If it returns ‘-1’, then you know it’s not there.

The other ‘benefit’, if you call it that, is that the table becomes dynamic and you don’t have to bounce/purge cache when you modify the table.  It gets loaded everytime the code is executed.

Hope this helps.

Steve

How about treating your OBX:5 as a list and foreaching it through the table for a non default result.

Try this out:

#! /appData/local/bin/hcitcl

global HciRoot

set tableName “$HciRoot/Tables/ndcTblRoute.tbl”

set tableLines [split [read_file $tableName] n]

if { [lsearch $tableLines “revdflt=*”] == -1 } {

   set tableStart [lsearch $tableLines “dflt=*”]

} else {

   set tableStart [lsearch $tableLines “revdflt=*”]

}

incr tableStart 2

set tableLines [lrange $tableLines $tableStart end]

set index 0

while {$index < [llength $tableLines]} {

   lappend listInbound [lindex $tableLines $index]

   incr index

   lappend listOutbound [lindex $tableLines $index]

   incr index 2

}

puts “inbound:  $listInbound”

puts “noutbound:  $listOutbound”

The tcl script is a goo idea.

I have the same script as a proc except my proc creates a keyed list where the input to the table is the key and the value of the table entry is the keyled list value.

The keyed list works well on a uni-directional table.  A regular works better on a bi-directional table as you can search either side and grab the corresponding entry on the other.

Good point, Steve

Abe

The keyed list works well on a uni-directional table.

We use arrays as tables extensively.  In most cases, these are one-off, in some cases we get the users to maintain a spreadsheet and then simply process this to generate the array ‘table’ contents, so we don’t manually change the tables.

Some of the LAB test translation ‘tables’ contain more than 1000 entries!

eg

proc ReligionFn {aCode} {

               # make the array global, so it is always available

       global ReligionFnArray

               #

               # Initialise if applicable

               #

       if {[array exists ReligionFnArray] == 0} {

               set ReligionFnArray(4SQ) {FOUR SQUARE}

               set ReligionFnArray(AGN) {AGNOSTIC}

               set ReligionFnArray(ANG) {ANGLICAN}

…

               set ReligionFnArray(UN) {UNKNOWN}

               set ReligionFnArray(UNI) {UNITARIAN}

               set ReligionFnArray(WIC) {WICCIAN}

       }

               #

               # set the return variable to the default, in this case the original

               #

       set myText $aCode

               #

               # Make sure we don’t fall over if there is NO data!

               # Set the array id and go for it

               #

       catch {set myText $ReligionFnArray($aCode)}

               #

               # return the data from the array

               #

       return $myText

}