Walter,

>I have one thing to add to this. How about database access ?? It seems more or less going through a same mechanism where you have to interface between fields of which you don't know the exact type and the strong typed variables in the language. How does the compiler handle that, since it cannot determine the type of a field at compile time ??

Well, you certainly have object which is variant type that performs similarily to a Fox untyped variable so you always can get object out of everything. But eventually usually have to cast to the proper type when calling this or that interface. Luckily that's pretty easy to do with either casting or the Convert class and since type information is available on just about everything it's usually pretty clear what you have to cast to (unlike C++ casting which is often a mystery <g>).

As pointed out by others there are some ways around this - using strongly typed datasets, or as I do is having a generator generate entity classes for me that represent the data as part of the business layer. This works very well for business objects that act as just plain objects.

For purely dynamic data (from dynamic queries as opposed to fixed record level queries ) that doesn't necessarily work though and you have to use the data as it comes in and perform casting/conversion as needed. Depends on what you do with it actually. Many things that you do accept object types - for example if you read data from a DataSet or DataReader you get an object, you can write out to Response.WRite() as an object and the framework knows what to do with the object looking at the type and figuring out what kind it is just like what a variant interface would do. As you might expect though there's a lot mroe overhead in doing the type lookups than specifying the right type in ther first place (including casting first).