Derek, Sorry for the delay in following up - had some urgent stuff to tend to
> > > VFP doesn't even compare with other RDBMS's in common use today. > > > Yes, sometimes the speed is comparible, but the featureset lags > > > far behind Oracle, MSSQL, and MySQL(free versions exist of MySQL > > > and MSSQL; possibly Oracle, but I'm not as familiar). > > > VFP was never designed to function as a database server, so I don't > > consider that a fair comparison. For our market, small business and > > niches within large companies, the power of VFP on LANS is just > > fine, without our having to resort to high-end ($) products. > > VFP sucks bandwidth. 100Mbps LANs are a must for our > application(10Mbps is noticeably slow). On the LAN front, I'm very encouraged to see gigabit Ethernet available, and talk of a 10 gigabit standard coming http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci535824,00. html > This is made worse by > a problem with VFP that causes it to read the first 20 bytes > of our dbc hundreds of times a second when running-- without > oplocks(multiple stations), this causes our app to take 10 > seconds to start! Compared to 1-2 seconds if there's an oplock. > DBF's also are prone to corruption, can't be backed up > online, and have no true security mechanism. With buffering, I'm not seeing corruption. And for important tables I keep audit trails of all changes made, for analysis and recovery purposes. For backups, 24x7 is the hardest case. Just gotta get users off to do the backups. Note that the audit trails help here, because full backups need to be taken less often. Security is a cat and mouse game that I have little interest in. I do support passwords and could implement encyption, but I steer clear of making general 'security' committments because there are just too many exposures. For example, there's nothing we can do to stop someone with physical access to equipment from taking screen prints or photos of screens, or even just remembering information. And these kind of exposures apply to any system. > We're comparing free to free(mysql/MSDE/MSSQL Express)-- not free to big $$$. It's not the free part that concerns me, it's the difference between a single integrated dev environment versus the multiple product approach - and all that entails. I see it as opting for a comfortable level of simplicity - at a price - versus complexity. > > minimum dependencies on any other product. It's hard enough > to master > > and control one product. Being responsible for and having to master > > and control multiple products at the development level is a > > proposition that I've gone through great lengths to avoid. > > That sounds like a craftsman that insists on using one tool for every > project-- be it a hammer, a screwdriver, etc. Sometimes you > need to learn more than one tool to get the project done right. VFP lets us go from ideas to executables, so it's a whole lot more then a hammer! > > My point was that the market, programmers, is heavy in the middle, not > > the top, and the 'average' programmer isn't about to become master of > > multiple products in any reasonable time frame. Therefore these people > > are better served with a "general purpose Swiss Army Knife" that they > > can do many things with today and also has plenty of room to grow with > > tomorrow. > > Maybe that's where I don't understand-- most of the good > programmers I know don't fit that 'average programmer' > category, and rather are able to command more than one > tool/language and excel at each. And then there are the > slower amongst us-- I'm personally more than happy to leave > them in the dust-- everyone can't be a programmer/developer. But we're talking about a dev product, so the audience really is the 'average' developer, which is my point: that VFP has a place in town. > > You're into fancier screen stuff then I'm up to, so I can't offer an > > answer to the problem you're seeing. > > No one can. Save maybe the VFP team themselves, but that's > unlikely. I believe they're bitblting the screen and then > drawing images on top and that's what's causing the > flicker... I'm sure they did that for performance reasons > with more 'normal' VFP applications, but our highly graphical > application is not typical. > > > > As to the "legacy" part, I don't even see it until someone mentions > > it. > > Go into VFP and create a normal control of any sorts on a > form. Look at the property list-- heh, look at just for the > form. You'll see a huge number of the properties are old > properties and methods that are not used in the VFP age-- > they're there for more legacy 2.x and older stuff. Many of > the properties are even for MAC-- I can't understand why > those couldn't have been hidden at some point, considering > VFP9 can't even compile MAC VFP apps anymore, AFAIK... Agreed > > It's dying. xbase is a file-based RDBMS. The years of file-based > > > RDBMS's ruling supreme are far behind us. We're in the time of > > > server-based RDBMS's. > > > But you know it's also a client for the various backends, thus it's > > only real weakness is not being a multi-user server engine itself. And even > > There goes one of(possibly the biggest) benefit of VFP-- it's > data engine(save for local cursors where it's not as > significant a feature and not used in n-tier apps as much). > Beyond that, the only thing VFP offers beyond the other more > mainstream tools would be a built-in report designer, as > inferior as it is(improved in VFP9 somewhat). Overall, I believe the xBase/VFP approach makes too much sense to discard. We'll see what actually happens, but I think competitors will be encouraged by MS's move, and over the next decade we'll see some very interesting developments wrt this paradigm. Bill > > > -- > Derek _______________________________________________ Post Messages to: %(real_name)[EMAIL PROTECTED](host_name)s Subscription Maintenance: %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s OT-free version of this list: %(web_page_url)slistinfo%(cgiext)s/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/%(messageid) ** 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.
