>The person before me declares most of the arrays public and never releases th em >after the screens requiring them are closed. I have experimented a little wi th >using release array and it has helped already. I am unsure of the correct wa t >to release the arrays. Will using release arrayname do the trick by itself or w >ould it be better to redimension them to [1,1] as well, or do I even need to re >lease them or can I just redimension them? In this situation just redimensioning them would be easier, because you don't have to redeclare them as public etc; you may just call the routine where these are dimensioned and filled when you need them. I don't remember that much of 2.0 to know exactly what happens to a public variable if it's released from another routine; I remember that in some versions it didn't release them at all; redimensioning would be the safer way: they don't lose scope, you can't accidentally create a local array (which would surely break if then you tried to redeclare it as public - it gives (imagine) a "syntax error", which is hard to understand). Where you may stumble upon is if these arrays are used at various places aound the app, relying on their values. In that case, it's just dirty (not sure of "quick and") and poorly designed. If the arrays are used rather locally, you're lucky. Dimension them and fill them when you need them, and minimize them when you don't. You can use filer to check all the *.prg;*.?pr files for the occurences of these arrays, just open the filer with these files and click on "find". >I also have users who get the too many reads in effect error occasionally. The limit was four in FP1.0x and it's 5 in FPx2.6; don't know which applies to 2.0. >well enough to know how to get around this error. Is there an easy explanati on >of how reads work and how to keep the read level below maximum? Unfortunatel y >I learn better from verbal and demonstration than from reading a book and I h av >en't found any one where I live who remembers this old version of foxpro. Tha nk >s again for all your help Dragan. You get multiple read levels when you use foundation read (i.e. start with a read without any gets, just run everything from its When, Valid, Show or other function. Then, in one of these functions, you may issue another read, up to the 4 or 5 levels, depending on version (if your helpfile was ok, you may have looked at it - BTW, USE Foxhelp and browse it. These things are in the first twenty or thirty records).You actually get a new read level if you issue new Get... Read from any function called from a Valid, When, Show, Message, RangeHi/Lo (forgot some?) functions during a current read. Now there's an easy way out: if RDLevel()>4... you may not issue new GETs. You may, but you may not issue a Read. Maybe you can activate another window, close it with a Keyb "{Ctrl+w}" Plain and then resume (much depending on the programmer's preference - I've never had a problem with this because my DOS apps are practically modal; the other Read windows are opened only on demand and by app's permission, and _not_ from the menu or via hotkey), or simply inform the user that too many input windows are open and he'd close some, and then get the hell back from that routine and don't start new gets and new reads. You may also issuing Clear Read but depending on the construction of the app it may work like a charm or like a spell; here's what FPD2.6 help says about it: CLEAR READ [ALL] CLEAR READ exits the active READ, and returns control to the previous READ level if the active READ is nested. READs can be nested up to five levels. When CLEAR READ is issued, the READ isn't immediately terminated. Any commands that remain to be executed before returning to the READ are executed. FoxPro supports nested READs. A nested READ is created by using a VALID or WHEN clause with @ ... GET to call a user-defined function containing additional @ ... GETs and a READ. READs can be nested in this manner to five levels. CLEAR READ terminates the READ on the current level and returns control to the previous READ level. Including ALL terminates all READs on all READ levels. CLEAR READ will not terminate a READ issued with no previous @ ... GET statements. In this case, READ VALID is executed when CLEAR READ is issued. If the READ follows @ ... GET statements and has a VALID clause, the VALID clause is not executed when CLEAR READ is issued. For more information on commands issued with no previous @ ... GET statements, see the Foundation READ section in the READ topic. The Foundation READ was an incredible kludge, but also a brave attempt to achieve some modal/modeless behavior of input windows in FP, and some other nice behavior issues. In the foreword to VFP 3 help, they said that it was just due to effort of programmers that it sometimes succeeded in emulating an event-driven environment, though it was definitely not one. It probably worked nice once you got it and got to know all of it quirks and dark corners; I've never used it. If your app uses it... well, I wonder what's it like; help may be not enough, you may need luck, too.