Segmentation violation

George flowersoft at compuserve.com
Sat Dec 8 14:54:04 PST 2007


In a case where people had < 9999 lines of code and still hit this
boundary, I think that falls under "misleading published performance
characteristics".  The specs only cite lines of code possible per table,
not some arcane limitation based on the end result size for the VM.  The
short version is that nobody cares about the internals.  They were promised
it could do up to 9999 lines of code, and ";" was a valid operand
separator--they should have been able to pack as much code into 9999 lines
as physically possible because the published product specs say so in an
unqualified fashion, TTBOMK.

mark->
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
http://mailman.celestial.com/mailman/listinfo/filepro-list

I totally agree.  My input table is only 4300+ lines and I cannot add many
more lines because of this limitation.  So, anything else I need to add to
this input table has to be via a "called" table or I have to move existing
code to "called" tables so that I can add more code to the input table. I
already have 387 "called" tables and 14 "chained" tables being invoked from
this input table, which negatively affects performance.  If the 9,999 lines
were truly available I could have probably fit most of the code in the input
table.
So the 9,999 line limit is similar to the 160 MPH mark in your car's
speedometer, it is there but unlikely to ever be reached.



More information about the Filepro-list mailing list