Hi Paul:
Just in case you didn't already think on possible setting's that can affect the performance heavily, and you keep looking what is different in VFP 9 that can make things so slow, I give you one that could be the responsible:
Using for..each for looping into a VFP object without using the new keyword FOXOBJECT I think that it is the most important change that need a code change to maintain compatibility. If the for..each is for looping a com object, then no problem, but if the object is a VFP object, then not having the FOXOBJECT keyword make VFP treat the object as a com one, making it's access really slow
El 19/6/2017 2:55 p. m., "Paul Hemans" paul_hemans@laberg.com.au escribió:
Koen, honestly why I am using vfp8 is a long (frustrating) story. The short story is that I wrote a huge development environment with its own compiler, I won't bore you with the details :) suffice to say that I am not kidding when I say it is huge. It runs fine under vfp8, but under vfp9 something changed internally with the string handling. One of the features of the environment is that the compiler turns html with embedded vfp into classes. Under vfp9 this process runs incredibly slow. Under vfp8 an installation (which is when the compiling happens) takes about 20 minutes, under vfp9 it took 6 hours. I have spent a lot of time trying to sort it out. I have played with the memory settings and with the coverage trying to track it down and in the end, I hate to say it but it beat me.
On Mon, Jun 19, 2017 at 10:36 PM, Koen Piller koen.piller@gmail.com wrote:
Paul, upgrade to VFP9SP2 and make use of FoxyPreviewer. FoxyPreviewer has different export/saving options, amongst HTML Easy to use. Why do you stick to VFP8 anyway? Regards, Koen
2017-06-19 1:03 GMT+02:00 Paul Hemans paul_hemans@laberg.com.au:
Is anyone aware of a utility that will take a vfp8 report .frx / .frt
and
convert it into some form of html template? To clarify, I am not
looking
to
run a vfp report and have it output in html.
We need to take a number of fairly simple reports and permanently move
them
to html. I expect to have to do some editing to clean them up.
The application currently outputs pdfs from frx and they are presented
on
the web. However, to better support i18n the database is moving to Postgres, and the code to JS, that leaves a problem with the reports.
Thanks.
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]