>1.) Is it quicker to read data from an array or a RECORD, or are they >the same speed? >2.) How can you place thousands of lines of RECORD data into a resource? > >Oh, one more (note the last line in the example below): > >BEGIN RECORD myData >DIM areaCode AS INTEGER >DIM city AS STR63 >DIM state AS STR15 >DIM timeZone AS STR15 >DIM otherInfo AS CONTAINER >END RECORD > >Is this legal? > Ken, I didn't know the answer to this, so I tried it. Here's what the compiler informed me: "Error: Containers may only be created as Globals and may not be in a register or part of any record." So, it's not legal. What is legal, though, is to use DIM otherInfo AS HANDLE I would do something like this: BEGIN RECORD myData DIM areaCode AS INT DIM city AS STR63 // See 1 DIM state AS BYTE // See 2 DIM timeZone AS BYTE // See 3 DIM infoHndl AS LONG // See 4 END RECORD Dim 1. I've left the city name string here, as there won't be THAT many duplications and searching will be faster without the additional lookup. 2. There are only 50 states, plus a few protectorates. Why use 160,000 bytes when 11,000 will do? (That one byte for each of 10,000 records, plus 1,000 for the 50+ strings. 3. Only 24 time zones--5 or 6 if you're just talking US. Same deal as the states. 4. This is where you use a trick I've just invented. It's untested, but I'll bet it works. Create just one container to manage all your "other info". DIM otherInfo AS CONTAINER As you create the records, when there is other info to read, use these 3 steps: 1. Read the info into the container: READ temp$:otherInfo = temp$ 2. Copy the container handle into your array: myRec.infoHndl(i) = [@otherInfo] 3. Zero the container THIS WAY: &@otherinfo, 0 The 3rd step is essential, because it makes the runtime "forget" that it had created a container there. If you instead use otherinfo = "", then the runtime will DESTROY the handle you just saved and it will become useless and dangerous. Similarly, if you just put the next value into the container without step 3, it will be put into the same handle you saved in the previous loop, eradicating the previous information. A nice benefit is that once you have the data in, you can access or change it just by copying the handle back into the container address: &@otherInfo, myRec.infoHndl(i) Now any change you make to the container will be made to the handle stored in your array! You don't even have to copy it back--just replace it with the next handle. One caveat--if you do eliminate the data altogether with otherInfo = "", you must explicitly zero the handle in your array: myRec.infoHndl(i) = 0. If you want to remove the info, it might be safer just to use: DEF DISPOSEH(myRec.infoHndl(i)) (though NOT if it's a resource!) Now, as far as putting all this into resources... I'm not familiar with that, but I'm sure Alain or someone can show us how. It may work best to save each otherInfo datum as a separate resource, and put resource IDs in your array instead of handles. Personally, I would probably just save it all in a separate data file, where there are no length limitations, and be done with it. As always, let me know where I have provided new and better confusion. :-) 0"0 =J= a y "