>My point it it's unfair to blame a technology because one developer has difficulty making something work correctly.

It pushes you towards what it likes to do. It's easy to do things the way of tool A in tool A, now tool B has other strengths and weaknesses, and doing in way of tool A in tool B may be hard. Sometimes you need to rethink a lot.

>I had a difficult time making my wireless network card work on my laptop using Ubuntu (which I believe you recommended to me). Did I blame Ubuntu? No, I blamed myself for not having the knowledge of Ubuntu or Linux in general to make it work.

Which then stopped working for me, then I forgot about it for a while, then all of a sudden started working again... don't know why not and why yes.

And the underlying problem was that Broadcom's wireless gear requires a piece of proprietary software downloaded from their website, or bought. Guess who has no legal problems getting those few hundred bytes, and who has.

The workaround for that was automated meanwhile, but not quite successfully (it would download from Broadcom, but it wouldn't kick in or something), now that works.

>I find it hard to believe that .NET can't handle the functions of the UT. I think it's more practical to point a finger at the architecture instead of the technology. What is so advanced about the way the UT works that .NET is not suited to handle, as you suggest? I have no problems retrieving records with longer memo fields. I have no problems turning longer pieces of text into .aspx pages.

My guess is that there's some piece of UT's architecture that doesn't sit well with whatever UT.net uses for data, and with which VFP was quite at home. Well, maybe if Michel decides to write a book...