Ragnar Hojland:
	I'll restate my problem again. ...
	That is:  find the value of a variable, referencing that
	variable by the means of a string with its name.
	
OK, I lied a little bit.
Global variables, pool variables, and class variables *ARE* objects.
(They are Associations held in dictionaries.  If you have a class
that has some class variables, 'TheClass explore' will show you the
dictionary and you can see the Associations in it.)  Compiled code
points to those objects.  Getting your hands on one is possible,
but not easy, and really REALLY not recommended.

However, method parameters, block parameters, and local variables
(the variables that begin with lower case letters) are *NOT* objects.
Smalltalk doesn't even have an analogue of Pascal 'var' parameters.
The only thing that can change such a variable is an explicit
assignment operation in the method that owns it, and parameters can
not be changed.  It's an 'encapsulation' argument, and one reason why
I'm happy with variables that are not objects.

I thought the original example was really quite explicit:
given the name of a variable, find its value.

For me the real problem is relying on a pun between SQL names and
Smalltalk names.  That's clearly very much against the spirit of SQL.

A question I didn't think to ask is 'What does SQLFields represent?
What can you tell us about that?'

It ought to be possible to adapt the ODBG Smalltalk binding to produce
a reasonable sort of SQL Smalltalk binding.  The new modules work in
Squeak 3.3 should make that a really attractive approach, because then
the Squeak class namespace could mirror the structured SQL namespace a
bit more clearly.