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.