>I guess I'll have to disagree with some of that paragraph.
>multiple forms = multiple web pages
>joined data files = not a speed issue if designed well
>just pop it on the web = you're right about that part being difficult
>slow as molasses = with client-server orientation in returning small >recordsets, I think molasses is a bit extreme
>look like crap = depends on who's designing them
>and take forever to code = with a good web-oriented framework and some >experience with HTML, DHTML, Java, VBScript, it's not that difficult. Again, >depends on who's doing it as well as the methodology used.
David..... I take your point on all of the above. My point is that I believe native VFP with a fat client, running using the native FP tables on a LAN is going to look and perform an order of magnitude better than the same application run over the web. I've seen a couple of major conversion projects in the 50-100K range founder on the promise of running the thing over the web, where the developers were attempting to port a very complex multi-page, multi-table application to Java and later html. The results were a disaster.
I agree completely about the n-tier design. And it isn't that I'm not working on webbifying things; but to date the results have been mixed; my web apps look like dbase II applications (@AT SAY? ) compared to my VFP apps.
Best wishes, --- Larry
-- Larry Keyes
Remember only You can prevent Gray Goo. Never release nanobot assembers without replication limiting code.