DRAGON CITY SYSTEMS
Vast Smalltalk Problems ( Bugs if you will :-)
Written July 2006
As I find more problem of interest I will post them here, they may in
fact not be bugs,
just misunderstandings of VAST and Smalltalk in general on my part; so
feel free to dismiss them or not as it pleases you :-)
1) Programmatically extracting data
items from a ODBC results set.
What I wanted to do was access the resultsSet of a
MultiRowQuery programatically, ie: get the data and manipulate by my
own code. I was quite happy with using the standard generated
form feature of MultiRowQuery to display this data on the form.
I originally tried to do the example from the VAST DB users guide,
Pages 28 - 29. Section "Displaying rows as strings"
only to find that it just did not work as described!.
Problems I encountered: ( note: I was using a different SQL table to
the example)
- I never achieved the results like those displayed in
para. 5, where the list box displayed the row contents as a continious
stream of characters, seperated by left and right brackets. I always
displayed blanks!
- I never found ANY iterator tool that would process the rowsAsStrings attribute as
described in the manual.
- I may have missed something, but I never managed to get
the method on page 29 1) to execute, missing #IS_Rows
error was reported in the debugger.
- Similarly, the details on page 29 2) never achieved the
declared results. I never did find the 'attribute-to-script'
connection!
- Also note the explaining graphic is so small the you
can't actually see the VA connections anyway !!
So, after help from the VAST news group, I tried a few ideas, and
achieved the desired results thus.
Wanted result:
The VAST Form setup:
You press the 'Load Diary' button, a
MultiRowQuery (MrQuery)
executes some SQL code ( against a Intersystems Cache' DB using ODBC
here),
which displays the Grid via zestAllRecs
resultSet 'tear off'. After the SQL code is
sucessfully executed, an attached Method (listItems ) then iterates
over the resultSet (zestAllRecs)
and forms the lines in the List Box. The connection
between MrQuery & listItems is a event 'onQuerySuccessful', the
connection from listItems and the ListBox is 'normal to items'
.
The result of listItems is the same
data untouched - its an exercise after all !
The SQL Query :
Select ZestDiary.bookingDate, ZestDiary.bookingTime,
ZestDiary.bookingDesc From ZestDiary.ZestDiary
The query is defined 'inside' MrQuery
Properties.
( Note this is SQL for Cache' , other SQL's will differ)
The method : listitems
listItems accesses the resultSet directly via code, ie: no VA
connection lines are used on the form, the lable (name) of the resultsSet icon
is
used, ie: the subpartNamed 'zestAllRecs' in the below code.
!ZestDiary1 publicMethods !
listItems
" this code is attached to a SQL QUERY, if query is sucessfull this code is executes,
it traverses the RESULTS TABLE of the SQL QUERY
and forms a OrderedCollection of Strings ( each string contains 3 fields )
Note: 'zestAllRecs' is a resultSet of the SQL Query
The collection is displayed in a list box on a form.
"
| items address rows rec |
items := OrderedCollection new.
((self subpartNamed: 'zestAllRecs')
valueOfAttributeNamed: #rows selector: #'IS_rows')
do: [:each |
each isNil ifFalse: [
address := (each at: 'bookingDate') asString, ', ',
(each at: 'bookingTime') asString, ', ',
( each at: 'bookingDesc').
items add: address.
] ].
^items. ! !
Summary:
The problem appeared to be that the published code expected to
be accessing instance(s) of
AbtQueryResultTable (actually
AbtMultiRowResultTable or AbtSingleRowResultTable
however the actual instance was '<something>ofRows, quite different.
Marten Feldtmann's posting kindly showed how to find out just what
instance type I was actually trying the process
by executing this code : (self subpartNamed: 'zestAllRecs')
inspect. ( or something similar) inside listItems.