Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Safe limit size for EXE file in FVP9

Piotr Czekalski

Programmer
May 17, 2024
40
0
6
PL
Hi all.

I have 2 similar projects in VFP9. I would like to join them in one. I compiled them for a testing and the EXE file size was about 800 KB.

I would like to ask experienced colleagues. What is the safe limit size for EXE file in FVP9 ?
 
Thanks for the extensive explanation. The old project (DOS interface) is written in VP6. The second one with Windows interface in VP9. I moved the required code fragment to VP9, made some corrections. Tt'is slowly visible that it will be working.

There is a question. Is processing DBF tables more efficient by VFP9 than VFP6 ?
 
Last edited:
Depends how you process them. The major optimization with Rushmore has not changed that much, but the VFP9 help has some things to say about the optimization of counts while SET DELETED ON being better optimizable, there's also the binary index type and of course several new field types. We already talked about autoinc, other types like varchar mainly are added for simpler usage of such column data types from SQL Server, a varchar(X) does not make a record in a DBF have variable size, for example, the DBF structure still has fixed length records within the DBF file aka RECSIZE(). Any fields with variable length are put into fpt files, as always.

The only profit about varchar instead of memo is, you can read back a varchar field like a memo field without trimming. If you store "Hello, world!" you get back "Hello, world!" not "Hello, world! " padded to the right with spaces. Still the string is preserved as saved. The way it's padded to the field length is with CHR(0), and those zero bytes are removed from the value when reading it back.

What has improved quite drastically is possibilities of SQL queries, much more possibilities for subqueries, for example. And in that, I'm sure, also is potential for better performance.
 
Hi,
to reduce ramusage / speedup I recommend :
  • have a look on sys(3050,1,xxx) and sys(3051,1,yyy)
  • have a look on sys(1104) and apifunction SetProcessWorkingSetSize()
  • doevents force in loops and after starting excel for automation
 

Part and Inventory Search

Sponsor

Back
Top