Hi bonnie

>Hope you don't mind me jumping in here with a few comments.

As long as we can take this constructive.

>>>There is much to say about strong vs weak typing. I´ve got experience in both, and I must say that when doing for example C++ bypassing problems that comes with strong typing (as you might not know the type of object that will be passed) seems more a problem than the problems that come with weak typing.
>
>I haven't used C++, but I can tell you that it's not really a problem in C#. You might not know the type of object that will be passed, but you can certainly test for the appropriate types.
>

>if (MyObject is TextBox)
>  o = (TextBox)MyObject;
>

>So, no big deal...

What you do there is casting, and this indeed is a feature found in strict type languages. I was refering to constructs where strong typing is used to validate the type where a parameter might be of unknown class. For flexible and optional parameters in functions you've got to use overloading in C++.

Now, strong typing serves two purposes: 1. Prohibit the developer to make mistakes in programming and avoid runtime errors (Datatype mismatch for example). 2. To give the compiler the possibility to optimize.

1. I don't feel I really miss this feature in VFP. Of course I get errors that could have been prevented with strong typing, but I know at first hand experience that programming in a strong type environment often adds more frustration because if I just forgot to do some casting on a variable that would not cause any compilation problem in VFP because it is not neccesary there.

2. I wonder how this related to .NET as the .NET compiles to intermediate (CLR) code instead of machine code. .NET code is just like VFP intepretated, which IMO makes this arbitrary.

>>>The fact is that if you have to implement a SQL query on local data in ADO.NET, you´ve got to program a lot. As a result, there it is more difficult to write bufree code as you literally have to program the SQL command. The risks of having a bug in there is much more a problem than writing a single SQL command. Readability is harded because a developer has to wade though the code that access the collections and objects and trying to figure out how thing are done. With a simple SQL command this is not a problem because you´re not interested in how this is handled internally because you assume at forehand it is bugfree.

>Sorry, Walter, but I don't see why you'd assume *anything* is bugfree. A single, complicated SQL command can have a bug in it just as easily as anything else.

Read carefully what I wrote... sigh...: With a simple SQL command this is not a problem because you´re not interested in how this is handled internally because you assume at forehand it is bugfree.

The argument is about the internal handling of the SQL command, not the SQL command itself. The case argues that if you've got to implement a SQL query in ADO.NET by iterating through collections and/or calling a collection of ADO.NET methods, you have to do a lot of programming to mimmick the SQL command (The SQL SELECTs internals). In this process you can write a lot of bugs because these types of queries normally are not simple.

The other side of course if making an error in translating the SQL command into a ADO.NEt solution which equals the risks of writing the wrong SQL command at first hand.


>>>The dataview must be build up and for all the internal handling behing this process and absense of the index ´concept´ this is performance wise not any alternative to the very quick DML of setting an index and drilling down that to get your data.

>Well, setting up a DataView in ADO.NET is a piece of cake. Here's a simple example:
>

>DataView oView = new DataView(MyTable);
>oView.RowFilter = "MyColumn1 = " + Column1value +
>             " AND MyColumn2 = " + Column2value
>

>Now, I haven't benchmarked anything performance-wise between using a .NET DataView versus using a VFP index ... but have you benchmarked this at all either? I bet there's not much difference.

Do you have any idea how this works? The dataview does not have any concept of indexes or optimizable expressions. With a VFP index the index is used as a very efficient tool to get your data. It is grouping the data based on index information, withouth touching the data that does not match your criteria. However if you are going to do this in .NET it has to examine every row if it matches the criterial just like a VFPs SET FILTER that is NON OPTIMIZABLE.

This might not be real performance killer with small resultsets (as using indexes also has an overhead, but is a bigger problem on larger sets of data).

Walter,