no, it's not difficult. you just SET COVERAGE TO , run the slow part of the app, then open the file that was created in the coverage profiler. I just heard yesterday about a download here that does a better job than the native coverage profiler, so maybe you could try that.
>I'm not familiar with the coverage profiler although I see it's in the help file. Is it difficult to learn? > >>If the hardware key isn't the problem, you might have to install the vfp development version on the system and use the coverage profiler to see what's going on. Actually, thinking about it, is the coverage profiler now available in the runtime? >> >>>We are using the same data in both instances. It is also local in both instances although in different folders. >>>Both PC's have lots of surplus drive space and the same hardware except the user's PC has a hardware key specific to a piece of software I don't have installed. We're going to test it with the key removed. >>> >>>>Is there any difference in the data, or where the data is stored between the two PCs? For example, does the user's PC have a different set of data, or does tha data reside on a network share somewhere off the user's PC whereas you are using the data locally on your development PC's hard drive? >>>> >>>>>Does VFP run faster in the development environment than in the runtime environment? I didn't think so but I have 2 basically identical PC's one used for development and the other (my user's) ion which the compiled runtime is installed. My routines run in about 5 minutes on my PC and take over an hour on my user's. My gut tells me the problem lies with the user's PC and not with VFP but the maintenance crew can't seem to find anything wrong with the second PC. >>>>> >>>>>Any thoughts?
