Hi John,

I fully agree here. And sure there are many VFP programmers who do abuse the capabilities beyond reasonable merit.

That is why I say that common wisdom often comes because of the limitations of they way of working or their tools. To stand above that is sometimes hard, but those ones who are able to do, have a much better understanding of the limitations they set for themselves and can more easily see how certain problems can be avoided.

Walter,


>I think there is wide agreement that it is definitely a bad idea to download large datasets to the client if you're using dotNET. The limitations of large memory-resident data are well understood and MS has committed to get some sort of auto disk spanning with Linq. Even so, if you google "dotnet local database" you'll see "experts" advocating exactly this.
>
>It is worth noting that you can download a dataset to a local Jet database and process it there, or a SQL Server 2005, or there are various add-on products to avoid memory-resident datasets in dotNET. But still, an indexed persistent local cursor is sometimes hard to match. ;-)
>
>IMHO the key is to be *able* to solve tasks sensibly in lots of different ways. Then you can make true technical decisions based on things like "merit" and "customer need". Otherwise there will always be a tendency toward Junk Science, with a process of compiling "proofs" to justify a predetermined choice. This applies to VFP just as much as C#, btw. Some of our habits in VFP aren't so hot. ;-)