>>I know there has been a lot of discussion recently of Access' 30,000 record limit. Does the same limit apply to Visual Basic as well?
>
>I've been away from this forum for a couple of weeks and just noticed this thread while catching up on my notes. I was excited to see Michael's note that a knowledge base article had been posted on this issue.
>
>Unfortunately what I found was a well intentioned attempt to define an issue the writer had limited knowledge of. Filtering carefully the article states that "I like FoxPro better because I use and understand it and I don't use or understand Access. Therefore Access/VB is not as good because I don't know how to make it work."
>
>I don't have time to prepare a better comparison of two excellent products at this time, but promise to do so after the first of the year. I'm currently putting in 18 hour days working toward a January 5 deliverable.
>
>Back to the initial question. There is no 30,000 record limit in Access. Access, however, is not as efficient as FoxPro at handling large (100,000 record up) databases.
>
>It is possible to distribute data, interface, logic, rules, etc over as many machines as needed in either language. Two years ago I built an application for Peterbilt Truck that they required to be written in Access. It contained well over 100,000 records, was run over an old Banyan Vines LAN, and an FTP WAN that included real time connection between their plant in Denton, Texas and their home office in Seattle, Washington. The data was stored in six different MDB's, the user interface was in another, and much of the business logic was in still another. Data was also accessed from dBase files on the network.
>
>Peterbilt's manufacturing engineering department had specified Access after long investigation because: a) they believed it to be easier to maintain internally, without needing highpriced consultants (me), b) they believed it would be easier to scale up to SQL Server when they took the application system wide, c) the available talent pool for adding to, programming in, etc their completed application was far greater for the VB/Access package than for any other available combination, d) several of their engineers were competent users of Access.
>
>The application worked great (and is still working great two years later). It would have worked faster in FoxPro, but that was not what the customer wanted.
>
>FoxPro is a great product. For many applications it has become my product of choice. But it is not served well by its adherents making uninformed attacks on other development tools.
>
>BTW, since the consensus on this forum seems to be that VB does not support OOP and can not be subclassed, I'm also planning an article after the first that will explain how to use Objects in VB and FoxPro, how the VB Object Browser works, how to sub class in VB, etc. This is not the place to post this information, but I will post a note with a link address, just in case anyone would really like to have the information. Since more code is being written in VB at this time than in any other language, I believe it is in the interest of any professional developer/programmer to have accurate knowledge of the language and its capabilities. I personally am finding it to be a great complement to VFP.
>
>Sorry for the long post.
>
>Best wishes.

James,
Point taken.. But also in this vein, you have to understand, that VFP is NOT pushed as much as ACCESS and VB... VFP in a lot of developers minds is a superior product, for doing applications that need a database engine, and a need for speed... Access and VB (which I am not totally familiar with, just read a lot on and seen some apps built with it..) do have their faults.. And from what I have heard, VB has a long ways to go, before it will have the OOp implimentation that VFP does..

Oh boy, I feel a lonnnnnnnngg thread coming from this..

Thanx!

Tony Miller
Vancouver, Wa