>>>Hi Charles,
>>>I don't understand your beef really.
>>>
>>>I work with tables mostly and views occasionally.
>>>Reason for that is very simple. Speed, simplicity of development and YES reliability.
>>>
>>>If data volums are in VFP acceptable ranges (considering 2gig limit) then I see no point in cripling application by pushing it trough ODBC botleneck
>>>just because your framework said so.
>>>Ever since Optimistic Buffering and Transactions were introduced to VFP
>>>with few other goodies (session object for instance) you can build
>>>very clean and reliable apps that can work perfectly fine with native VFP dbcs/tables
>>>
>>>I remember sadomasohistic attempt by company I was working for, to build everything CS back in mid nineties based on dev buzz back then. Remote views via ODBC! We will deploy VFP database to small clients and MSSQL to big ones. And all that was expected to work on W95 clients and NET 4.0 servers back then. Bwah ha ha ha :)
>>
>>I think you misunderstand what a view based application is. It does not require ODBC at all if addressing VFP tables. It just is a way of working with the data that allows for parameterizing and creating less network traffic, denormalizing tables for purposes of display and reporting etc. It also means a lot less vulnerability to crashes that lead to corrupted data.
>
>Now in the morning , yes probably I did.
>
>But hey isn't there always more then one way to skin the cat ??
>Why are you so convinced that what your commercial framework did
>was the best thing to do, or that everything has to be done via one
>or more commercial frameworks ??

Nothing *has* to be done that way, but my clients pay me to solve their business problems, not to invent the tools to do it. By your logic, why use Foxpro? Why not sit down with C++ and write your own database language?

>
>I saw most of frameworks back then, learned a lot from them but only
>became trully free and at peace once I built my own :)
>I kind of got bothered with you constantly blasting <g> on people not using commercial frameworks, doing everything with SQL server etc.

Not blasting at all. I actually do quite well rewriting apps for clients who had someone who thought they knew what they were doing using VFP right out of the box with a few foundation classes agains DBFs. <g>

In a perfect world, I would be the only VFP developer using a professional framework <g>.


>
>Sorry but I beg to differ!
>This all depends on type of apps and businesses that you are dealing with.
>Weather you are contractor (like you) or It Mgr as me. You are seller but I am budget minded buyer!

>
>If I can *get away* with 100-200k less per year (in sadditional admin stuff, licences etc) then I buy all means go for it. I know most of my shareholders personally, so perhaps that makes difference in a way we go about the things.

I'm not sure where the 100-200k number comes from but I look at it this way. I know for a fact that it would take two of the best VFP designers in the world ( Mike an Toni Feltman ) at least 3000 hours to develop a framework and then hundreds of users another couple of years to really test, debug and suggest additional features.

I charge $125-$150 an hour. Even if I knew what I were doing, why would writing my own framework be cost effective ? Why would using DBFs - which many clients will not even allow on their servers, which cannot be backed up while open without writing specialized code to do so, which are not integrated into the operating system and which don't have most of the features of a true RDMS be a better financial choice than SQL when both are the same price ( free )

And why would I want to create table based applications when the implications for network traffic, data vulnerability and programming flexibility are so much in favor of using views, whatever the data backend.

>
>If I was out there seeking long term contracts perhaps I would be telling them; Yeah go buy MSSQL, Oracle this or that, I will be always there to help you (&bill you) and I would defenetely have all gear in place to do so :)
>

I do seek long term relationships with clients. And that is why I don't want to offer them a solution I'm going to be embarrassed about five years from now when their business has grown and their network greatly expanded.


>>Without a proper framework I have no idea how well views would work but without a proper framework ( one far more sophisticated than I would have ever built for myself ) I wouldn't' be working with VFP.
>>
>>And once you know how to write a view based, truly n-tier application with a real data layer, business layer, and presentation layer moving to a sql server backend is not very difficult.
>
>Agree, provided this is exactly what you need :)

If you are writing desktop apps that don't run on a network and will only be used by one computer by one user, then of course you don't need anything more than Access, Filemaker Pro, Foxpro 2.6 or DB III

I'm talking about multiuser apps in a networked environment.


>
>>
>>We all know what the problems were in creating sophisticated applications in FPw 2.6 without views. I can't imagine voluntarily doing that again.
>>
>>If you like DBFs for data that's fine, but that doesn't mean not basing your data layer on local views.
>>
>>And as to the cost - SQL Express is free and IMO a far better solution than DBFs.
>
>Disagree :)

Disagree that it's free, or disagree that a SQL Server is technically superior and offers the developer more options than DBC/DBFs ?
>
>>
>>It is difficult to concisely describe the development environment of VFE / Remote views / and SQL server but I have never shown it to anyone who was not amazed at how easy and powerful it is
>>
>>Disclaimer : though I do training and project mentoring for F1 Technologies and am a long time friend of Mike and Toni Feltman I do not profit from VFE sales. I also have a lot of respect for Mere Mortals and Visual MaxFrame ( and the work Hank Fay has done with Visual ProMatrix ). Cetin did some amazing stuff with Foxy Classes and I've seen other frameworks that had a lot to offer. I am not sure any of them have taken development of their frameworks as far as the Feltmans have but there I have a definite prejudice as developing apps with VFE has made me a *lot* of money <g>
>>
>> In any case, I really do believe most VFP developers don't realize how much of a productivity enhancement the proper use of a professionally developed framework is. And a lot of resistance to using Sql backends, working with views and writing truly n-tier apps I think is due to the fact that VFP right out of the box is really a very unfinished product. You can do great things with it, but first you need a framework.
>
>Agree 100%, except that I prefer building my own any day, then using someone elses. Learn from yes, use no.

How can you learn from a framework you don't own, use or understand. I think you really underestimate the complexity of the kind of framework I'm talking about. And since the framework is 100% customizable, why would it be more cost efficient to start from scratch. You do realize that frameworks cost lest than $1000 ? That's a lot of tested code for the money.

>
>>And it is very very very very unlikely a beginning VFP developer even knows >how much he doesn't know about what a framework needs. I would no more build my own framework than build my own car.
>
>VFP Beginners are different story; but how about experienced Foxers comming from DOS ? When it comes to frameworks and purpose they serve, I believe you overestimated little bit problem at hand and maybe underestimated your own self :)

I know what it takes to write the kind of apps I write. 20 years ago the kind of apps clients would settle for could be done with much less. Now I have the tools at hand to write better apps, faster, that will scale better. Why not use them? I can write a much better app much faster with the framework than without it. Never underestimate the power of a framework as a RAD tool either.

If you are writing VFP apps that bear resemblence to FP DOS apps then I see why an n-tier OOP framework would get in the way <g> I *am* an experienced Foxer from the DOS days - at least from 1985. That was fine for the computer world of the 1980s and 90s and the low expectations of clients but my god there was a lot of terrible code floating around.

VFP is a very very very different paradigm than FP DOS for an very different business environment.

I've been a fan of frameworks since Codebook. I also learned early on the difference in the skill sets of tool users and tool builders.


>I think of a VFP development more like of a building motorbikes;
>With all respect to Orange County kind of bike builders (Feltmans and others)
>If you knew how (and I know you do!), would'nt you wanna build your own custom bike ???

Do you charge your clients for the cost of framework development? Not very fair to them.

Amateur built frameworks vs professionally built frameworks ( and I'm not talking about 'experienced Foxers' fromm FP DOS I'm talking about professional framework builders ) are the difference between amateur built airplanes vs professionally built ones. I've flown in and flight tested both enough to have seen the difference <g>



>Cheers :)
>Sergio