>Alex, this isn't about what they will or won't do. Mike asked about what changes could be made to VFP as opposed to it's being a 'finished' product. I don't expect these things. I'm just pointing out that there are things that could be done if the product were to continue being enhanced. > >>>64 bit capability? >>Too expensive as it would mean re-writing major portions of the program, which they obviously do not want to do. >> >>>Better data integrity in the database container? >>Won't happen with an open data structure as it has. Any major changes to it would break backward compatibility. >> >>>Break the 2 gig limit? (not really sure this one is all that useful, but you asked) >>Would most probably break backward compatibility (which they always wanted to maintain), it would mean an expensive redesign, and (let's be realistic) would compete a little more with SQL Server which is where their money is. >> >>Why would they do that? I have VFP apps running DBFs and I have VFP apps running SQL Server. In fact most of my really big tables are in SQL Server (I have one with over 45 million records and growing at about 1.3 million a month). That app is all VFP, except for the big history table. The lookup tables are all DBF. I don't see a problem.
"Once again, we come to the Holiday Season, a deeply religious time that each of us observes, in his own way, by going to the mall of his choice." -- Dave Barry
