Hi Ken, Phil Yates wrote: > Far be it for me to suggest something that Staz hasn't, but personally, I'd > build an array (Array$(n,n)) to hold all the data, and whack this in and out > of the resource fork on startup / closedown (if it changes). If you haven't > got the code to move the array, let me know. > > On one project, I bring in about 10Mb on startup, and it's so fast you don't > notice it. > > Then, you can index the array how you like ... I think Phil has the right idea, since the data is known and does not change very often. I too like to have everything in a single package, vs the Windoze method of external files all over the place, that may be lost or misplaced. In the games, on which I was working for several years, Mac Versions had the two thousand plus questions and answer-options stored as STR# Resources. Worked fine and fast. When I got around to doing the Windoze Versions of the Games with Virtual Basic, there were no Resources to be used at the time, so I did exactly what Phil suggests. Even with bloated, sluggish VB apps, they loaded lightening fast. Some of the Questions pushed the 255 character limit of a Resource Str, AND the same limitation of an Array Element, so there were MBs of data being handled. I don't use Resourcerer, so I'm not sure that it has the same limitation, but once convenience of having the data in your code rather than in resources is that it is searchable by FB, in case you DO have to make changes or fix typos. IMHOFWIW, Joe Wilkins PS -- If you still want to try the STR# Resources, you can always have a constant you add/subtract so that item 679 becomes number 1, 680 - number 2, etc.