Alan, > > > No. Partly because > > I'm resistant to group-think and the mad rush to the Next Big Thing whether > > it's truly the right thing to do or not, > > I don't think a separate data tier and the use of a proper > database ser been the Next ver as opposed to a flat-file, insecure table > format with an increasingly flaky locking approach has been a Next Big Thing for a > good 10 years or more.
Let's examine the components of your (the) argument: 1. A "separate data tier" is achievable in software in all cases. Data is separate from software by definition, it's how it's accessed that constitutes a separate data tier design, and I've done that - to the extent I feel that I need to - with native VFP tables. 2. "Flat-file" is a pejorative that makes a big deal of the difference between data stored with fixed, rather then variable, length fields/records. Yes, I'll agree that variable is technically better, but it's really not the big deal it's made out to be. First, in ALL cases data is stored in memory and on devices as 0's and 1's, which is the essence of the proposition shared by ALL applications. Second, device storage capacities EASILY handle the increased storage space required for flat files. Third, data sent over a network is compressed by protocol. The big deal isn't the extra megs of device storage space VFP uses, it's the file size limit - but some of us have figured out how to design around it, making it not a big deal after all. 3. "Insecure table format". Ah, the dreaded "security" sword. The paranoids among us can use freely available encryption. 4. "Increasingly flaky locking approach". True, more then 1 person/process can't update the same record at the same time, but that's true for any system. From my perspective as a provider of software to small business with one or a few workstations, I'm just not seeing flaky locking problems, but if does happen, I'll figure out a way to deal with it. Application design, the right feature set, useful doc, reasonable pricing and outstanding customer support are what matters to customers. We can and do deliver these things with VFP only today. I'm not saying we should use cash registers instead of computers, but that VFP as it is is VERY suitable for MANY applications today and will continue to be so as far into the future as we can see today. I'm critical of the group-think mentality that caused some people to jump from VFP to multi-product (or different product) dev systems without thinking it through. No matter how you cut it, requiring a small business to purchase, install, understand, maintain and operate a multi-product system is more expensive and more complex then the simpler VFP-only system. Someone may ask "well, who cares about small business anyway?" I do! I love the concept that one person can choose to be self-employed (self-sufficient). A note-worthy related point: the jump to multi-product software solutions is intrinsically a jump for the small, independent developer into a larger and more expensive enterprise. But there's a boundary, a threshold, where the cost of starting and operating a small software business becomes too great for an ordinary person, and then the enterprise itself is consumed by the voracious and insatiable appetite of Big Business. That's bad, bad, bad. There's also the "joke is on us" angle with software dev for big business: where do you think big business is doing all the hiring? I'd like to say again that I'm really not against c/s, I'm just for what VFP can do by itself. There's tons of room for c/s, and I do use it internally, I'm just not buying into the bum's rush anytime soon. Bill > -- > Alan Bourke > alanpbourke (at) fastmail (dot) fm > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/0e0c4a99993e48008d908b14651aa...@bills ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
