Perhaps he did a performance analysis between VB6 and Access 2.0 of eight years ago. I don’t think even the most die hard VB enthusiast went down that road after A97; however, given that he gave him a real ride with little real proof, you are stuck with the result.
You do have ONE tremendous advantage in that this appears to be an application for in house use and you are not trying to find performance enhancements for off site locations.
A 300,000 record set is nothing for Access to get upset over. However, if you are dealing with all 300,000 on one form you’ve already found your problem. Not even the staunchest VB enthusiast would claim high speed here. My first suggestion to you is to find some time to sit down with your boss and find out from him exactly what is slow about the Access application. In most cases he is going to say, with a nasty grin on his face, this particular form loads as fast as his dog squats on a cold morning. Encourage him. You are trying to gauge his perceptions. Once you know what to him are the horrid results, in most cases you will find two or three forms, about twice that many reports, and one or two free standing queries.
In at least nine out of ten cases he is absolutely correct. Usually in almost all medium to large scale Access applications, there is at least one form that loads so slowly you can drink a cup of coffee and smoke two cigarettes waiting for it to finish. Spend a bit of time finding out which is the worst of the worst. Take that one and closely look at the underlying record source. In most instances, a user only wants to see between three and ten records; not three hundred or ten thousand. I have seen applications that pull back 10,000 records from a SQL SERVER database and then filter out 9,999 of them to display the one the user really wanted. Pour over that query. Break it apart. Create at least 5 queries that do the same thing but each one faster than the last, and each one bringing in far fewer records than the previous version.
I have not seen a record source that returns more than one record that cannot be improved or made faster. Realistically, Access developers cause the negative comparisons between Access and Visual Basic because of the quality of their results.
The best approach to take is to get a user assigned to test your work, and his /her one criterion should be comfort with the product. Is it easy to use, is it fast to use?
The only real reason many users feel that VB applications are faster than the Access equivalent is because since it takes on average three times as long to do the VB project, developers tend to spend much more time refining the product.
This should certainly get you started. It could possibly solve your dilemma.
Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com