>Kevin,
>
>That's one of the most impressive displays of open-mindedness I've ever seen. Walter, of course, is one very sharp dude, so to speak. Among his other points, I especially agree with Walter's assessment of the importance of dynamic, table-driven applications, and VFP's particular strengths in that department.

Sharp is not the word, he reminds me of someone I know actually, someone who has this ability to get right down the rock-hard facts, and that's exactly how it hits you - like a rock.

It's great to have people like him around, and I completely agree with what you've said above about his points, which is why I simply couldn't question them (hence the knock back to reality), he was spot-on, so much so that I felt I needed to commend him on his ability to do that.

Thanks
Kev

>
>>Walter
>>
>>I can't thank you enough for this, you've given some of the most detailed and realistic arguments I have ever seen that prove how un-realistic .Net is right now.
>>
>>I'm an active VFP6 & 8 developer, and there will come a time when I have to shift to C# full-time, I've always admired VFP as a language, but I could never have laid it out like you have done below.
>>
>>Thanks for making me see the light, a real light...:) I will admit I haven't been seeing the forest for the trees lately, but you've changed that - I just don't like to get too tied to one language and rule out the rest, I guess, or maybe it's because in my organisation we don't get the choice of development tools. Either way I hope you didn't think I was bashing Fox, because I wasn't.
>>
>>Kev
>>
>>PS No, I'm not being sarcastic either.
>>
>>>Hi kevin,
>>>
>>>>>Huh ? I don't follow this. If you don't want to tie an application to a certain development tool, why isn't VFP suitable anyways ?
>>>
>>>>Check out the title of this thread for a start.
>>>
>>>A nothing saying title which message we've been hearing for about 10 years now. So ?
>>>
>>>>When I say application I was mainly referring to Windows applications, database applications etc. Not device drivers or number crackers.
>>>
>>>IMO database applications are still best written in VFP, not .NET. Too many issues and workarrounds for what should be in there by default. .NET is despite what MS wants to believe not mature enough to write and deploy database apps as easy as in VFP.
>>>
>>>>>When it comes in handling and munging disconnected datasets on the client VFP is the real champion here.
>>>
>>>>Yes I know that.
>>>
>>>So, you agree with VFP is superiour when it comes to data munging. So if in a application lot's of data munging is used, why should I use .NET ? In data driven applications data munging capabilities are very important. Why deny the place of VFP in the market ?
>>>
>>>>>I don't see the relation between using a full blown OO language and the data it processes. They should be totally unrelated IMO. They've tried to harmonize OO and relational data, but aside from some experiment with OO databases the most efficient way to handle data is using relational data which might be handled in an OO environment.
>>>>>
>>>>>To be honest I don't see the the other ways. Data should be handled relational not in a OO way. Not because I say so, but since it is the standard. Handling data in an OO way is asking for all kinds of problems: The same problems which caused OO databases (on a large scale) to fail.
>>>
>>>>Do you have proof of this?
>>>
>>>Depends on what you call proof. Before the internet hype a new phenomenon was introduced: the OO database. After the Internet hype we don't hear a lot about those OO database anymore. 99% of all data is stored (more or less) relational, certainly not OO. SQL server is a relational database not OO. When connection to a relational database in .NET and want to treat the dataset as a OO dataset you've got to do a conversion and disconnect the datasource from the object model which is an extra (often not neccesary) step. VFP does this right by offering a method of binding the data directly to the controls. The step of loading the data in a OO hierarchy with collections is beyond me. It probably derives from the VB age and the windows activeX controls like the Treeview, listview, Flexgrids ect, where there is no way directly binding the data to the control (OLE db does fill the control, but does not establish a direct relation).
>>>
>>>Anyways in the DB world there is a consensus that though OOP is an accepted way of programming database applications the data stays relational. For more information I reccomend reading an equivalent to the dutch magazine DB/M (isn't it DB Magazine in England/America ?) to get the picture.
>>>
>>>IOW, I dont, (like many other professionals) believe in OO handling of database data. Relational data is easy to use since there is a standardize DML for it: SQL. In OO terms there is not much but propetary methods (Look at for example the outlook model where you have to use certain methods to filter and search upon columns to get a resultset. It is not even possible to get a resultset in for example XML without extensive programming). This is a reall miss If you ask me. It shows once again that MS misses the point even with one of their flagships: MS office. I have to becarefull here because I don't own MS office 2003 yet, so I cannot comment on the changes here, esspecially since I do know that XML is deeply integrated in this suite.
>>>
>>>>>As you stated above, handling data in an OO way is not the most efficient. In the case of .NET you might have some tools to help you on this, but nothing beats just the relational approach. As others have tried handling data in a Object oriented way is cumbersome and IMO, certainly not the logical choiche, no matter which environment you're using.
>>>
>>>>Again, I need to see proof of this, is it just your opinion that it is cumbersome?
>>>
>>>Again look at the way that Microsoft office (Version 2000 and below) handles data. Entirly through an object model. If for example I want to know the appointments for Dr X between today and the end of next week, I've got to write a program the get the data. Why ??? If I had the resources to build an equivalent to MS office I would have it made it much more easely by at least providing a relational method of getting the data: SELECT * FROM appointments WHERE person = "Dr X" AND AppointmentDate BETWEEN DATE() AND DATE()+7 and return the result in for example a XML string. Ever tried to synchronize your local appointment calendar with outlooks one? You'll have to do this through the object model, why not via a relational way:
>>>
>>>

INSERT INTO OutlooksAppointments (...) SELECT (...) FROM MyLocalAppointments WHERE AppointmentPK NOT EXISTS ( SELECT AppointmentPK FROM OutlookAppointments)

>>>
>>>and
>>>
>>>

DELETE FROM OutlooksAppointments T WHERE NOT EXIST (SELECT AppointmentsPK FROM MyLocalAppointments WHERE AppointmentPK = T.AppointmentsPk)

>>>
>>>Would you agree this makes more sense ?
>>>
>>>>>Take for example the Treeview and Listview ActiveX controls. They rely on an object model to store data. Though I can work fine with it, it still is cumbersome to tie your data to it. What if there was a possibility to directly connect your data to a treeview or listview. Would you or would you not agree that this is more efficient.
>>>
>>>>>Are you going to build programming languages in .NET (in its current state)?
>>>>
>>>>See point above, I'm not talking down to this level.
>>>
>>>Even at the point of database applications you'll find cases where VFP applications make more sence. You've already agreed upon the superiour data mungin capabilities of VFP. If you're planning to use them extensively why mudding arround with .NET ?
>>>
>>>Even if we look at one level up, the ERM, SAP packages where you develop on a total different level I see no place for .NET (yet ?). Back to the 4GL level, does .NET make delphi obsolete? I guess not. Why should this be the case for VFP? The only reason for that might be FUD, if you'd ask me.
>>>
>>>
>>>I know for sure these arguments are believed insignificant for all those poor .NET developers.
>>>It seems the same story about Interitance in VB6: It was insignificant. Now .NET has it and has more OO features than VFP (?) it seems to be the most important thing (pardon me ?!?). So when in .NET version x a local database engine was introduced I can see the headlines in the papers: Local Dataengine greatly improves .NETs flexilibity!
>>>
>>>Hypocritism ???
>>>
>>>sigh....
>>>
>>>
>>>>>Is .NEt cross platform?
>>>>C# is, I think.
>>>
>>>Is it ? Which platform?
>>>
>>>>>Does .Net make C/C++ obsolete?
>>>
>>>>>I certainly do not agree with this standpoint. .NET might have a wide range of application, but its definately not a platform which makes all other tools obsolete.
>>>
>>>>I never said it makes anything obsolete, I was merely talking about the humble developer who provides their clients with nice front ends that may deal with data, not device drivers or programming languages.
>>>
>>>Do you really think that the humble developer is going to be more productive in .NET than in VFP? I've seen other cases here on the UT. Productivity is one of the least heard arguments to switch to .NET. IMO, the vast majority of VFP developers will judge that productivity in VFP is better when doing reasonable complex project. Not to talk about the learning curve or handling the transformations .NET will go through to reach maturity.
>>>
>>>About the argument of NICE GUI's. Well most GUI's are bad because they're designed bad, not because of the limitations that come with the development tool. You can create very pretty GUIs in VFP as well. They're about rare I guess because good programmers seldom are great GUI designers...
>>>
>>>Walter,