Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd From: awd@dbase.A-T.COM (Alastair Dallas) Newsgroups: comp.databases Subject: Re: dbase IV "popup" while editing data with "read" command Summary: Sorry you had trouble Keywords: dbase, data entry Message-ID: <1991Apr22.170319.24538@dbase.A-T.COM> Date: 22 Apr 91 17:03:19 GMT References: <881@imec.UUCP> <1991Apr5.164724.4798@dbase.A-T.COM> <1991Apr17.110913.7460@bhpmrl.oz.au> Organization: Ashton-Tate, Inc. Lines: 71 In article <1991Apr17.110913.7460@bhpmrl.oz.au>, paulg@bhpmrl.oz.au (Paul Gallagher) writes: > > I want to mention a few BUTs, IFs and F***s regarding this admittadly > brilliant capability of dBase IV. > > ...details elided... > > I've nested this procedure up to three times, but in doing so, I had to > overcome some of the most frustrating, depressing, infuriating (etc) > problems I've ever seen. Nesting VALID clauses certainly lets you do some amazing tricks, but it stress-tests the underlying engine, too. Every time the interpreter must call itself recursively, there is the chance that we'll run out of memory (an invocation of the interpreter takes a fair amount of memory) and sometimes recovery of the current thread of execution (what we call the token stream) is impossible. When this happens, the next token can be garbage--we trap this condition (rather than executing off in deep space) and tell you "unknown command code." I know that is no consolation. > After hours of code reconstruction, line-by-line - a process > which is not exactly fast especially since I am only using a 10MHz XT - One problem the software industry faces is that developers like me get to use way cool hardware. The test department has machines like XTs around, but it's not something a developer plays with regularly. (In fact, we have software which simulates older, slower machines on fast new ones.) I'm not saying you should get a faster machine to run dBASE (obviously it's working for you as long as you don't stress it), but I am saying that software developers at companies like A-T, Lotus, Microsoft, etc. are going to have trouble relating to a 10MHx XT. (Oddly, we have trouble relating to high-end stuff, too--popular software in general doesn't take full advantage of the latest hardware.) > So, (allbeit without MESSAGES) I finally had the thing running. I've yet > to speak to A-T about this, but my best guess is that dBase IV (V1.1 btw) > was either having stack problems or perhaps not managing a lack of > memory properly, or even not managing it's own internal memory allocation > properly. All I can say is that our local A-T help line is damned lucky > it doen't operate at 2am else they would have had one hell of an earbashing! It probably wouldn't hurt for you to call your local A-T help line, too, but I will pass your message on to our resident nested-VALID-clauses expert and see if he can help. As for "not managing a lack of memory properly," obviously you are right and I'm sorry for any inconvenience this caused you. The fact is that you've caught us at a critical juncture-- the interpreter is provably recursive and the READ command can indeed nest. But when VALID clauses nest, and a resource error occurs, it is just plain difficult to extract the READ from the interpreter invocation, and the result is someone halfway around the world wants to kill someone at 2am. If we had seen the symptoms you are reporting, we would not have shipped 1.1. In fact, I have not heard these symptoms reported before this, but I can tell you what the error messages mean. > Thanks for the shoulder to cry on. I'd like to hear other's experiences > along these lines though. Is this a problem someone else out there has > had? I'd like to hear from anyone, as well. We believe v1.1 is extremely solid, and we're working to release v1.2 a little later this year--I'm impressed at the quality committment I feel from my management (the folks who took over from the folks who brought you dBASE IV 1.0). Let me know if I can help. /alastair/ -- |Disclaimer: I am speaking for myself, not as a spokesman for Ashton-Tate, |which does not monitor my outbursts here. I reserve all rights to my |opinions in terms of commercial endorsements.