Is it possible in QB45 to increase the available space required for any of the following out of space conditions? Out of String space, out of data space, out of stack space. I have a genealogy program which uses increased amts of stored data, strings and stack requirements as the number of generations to be displayed is increased. I am OK up to 11 generations back, but balk at 12. Believe I have tried all available methods in manuals to reduce these requirements, including Clear to set Stack space but have reached a dead end. I vaguely remember from long past that Basic sets up a work space called heap which is invaded from both top and bottom until they meet, then curtains. Have never heard of a way to increase this. I have 1.4 gig Athalon computer with 512 megs mem and 40 gig HD less than 1/2 full. Thank you Bdecker
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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Eliminating Out of Space Errors,- Data,-String-Stack in QB45 2
- Thread starter bbddkkrr
- Start date
-
1
- #2
The /AH swith will allow larger arrays, putting together
programs with multple bas files so that the compiler will
compile each separately then link them together will help
too. Setting subs as static, using defint or one of the
other options can help.
Trouble is, QB is limited not by available memory but by
it's own internal / dos limits which is basically 64k.
(less overhead).
There are libraries howver that will allow the use of
xms/ems memory that may help your problem too.
Also, keep line lengths under 100 if at all possible. Long
line lengths can cause problems compiling a program.
(might better get pbcc for text based program - your limit would be greatly increased)
(PowerBASIC Console Compiler for windows)
programs with multple bas files so that the compiler will
compile each separately then link them together will help
too. Setting subs as static, using defint or one of the
other options can help.
Trouble is, QB is limited not by available memory but by
it's own internal / dos limits which is basically 64k.
(less overhead).
There are libraries howver that will allow the use of
xms/ems memory that may help your problem too.
Also, keep line lengths under 100 if at all possible. Long
line lengths can cause problems compiling a program.
(might better get pbcc for text based program - your limit would be greatly increased)
(PowerBASIC Console Compiler for windows)
- Thread starter
- #3
-
1
- #5
Hey, pleased to meet you here!
Modules are useful as they improve the reusability of code parts, but the 64K of workspace is shared among all modules.
The heap can contain only dymamic arrays and those don't include variable length string arrays. Only numeric and fixed length string arrays can be dynamic.
The libs will allow to use EMS/XMS as paging memory to save big arrays, but QB will operate only with the part of the array in QB's memory. You can't perform searches directly into XMS/EMS from a DOS program.
EMS/XMS is mainly used in games where 60 frames per second must be generated from many separate bitmaps: in this case disk accesses would be far too slow.
But if you can wait for some seconds to have your tree built, I think you don't need to copy all your database into memory, a RANDOM access file -as we discussed elsewhere- should be enough.
Antoni
Modules are useful as they improve the reusability of code parts, but the 64K of workspace is shared among all modules.
The heap can contain only dymamic arrays and those don't include variable length string arrays. Only numeric and fixed length string arrays can be dynamic.
The libs will allow to use EMS/XMS as paging memory to save big arrays, but QB will operate only with the part of the array in QB's memory. You can't perform searches directly into XMS/EMS from a DOS program.
EMS/XMS is mainly used in games where 60 frames per second must be generated from many separate bitmaps: in this case disk accesses would be far too slow.
But if you can wait for some seconds to have your tree built, I think you don't need to copy all your database into memory, a RANDOM access file -as we discussed elsewhere- should be enough.
Antoni
- Thread starter
- #6
Hello to Shanley and Agual I was out of town yesterday and not home 'til late last night.
I don't understand how Shanley's comment applies but I do appreciate your responding.
So Agual, we meet again. You have given me much to think about and apply and have settled a number of questions I was unsure about.
As for putting the full data base in memory, by which I assume you mean the full Persons List as maintained separately, I don't bring it all in when generating my charts. Using a random array and accessing just the names required for any one individuals pedigree, I still run out of space abv 11 generations back. Will answer in more detail in my second try the other list.
Thanks both for your interest and help.
Bdecker
I don't understand how Shanley's comment applies but I do appreciate your responding.
So Agual, we meet again. You have given me much to think about and apply and have settled a number of questions I was unsure about.
As for putting the full data base in memory, by which I assume you mean the full Persons List as maintained separately, I don't bring it all in when generating my charts. Using a random array and accessing just the names required for any one individuals pedigree, I still run out of space abv 11 generations back. Will answer in more detail in my second try the other list.
Thanks both for your interest and help.
Bdecker
- Status