Actually, there was no information of that sort. I suspect that since it is a standalone compiled database (4D Volume Desktop) it is unlikely that there will be any line numbers associated. If there should be, I did not notice any.
Now 5 days later and still no reoccurrence. There is something else that I did fix, but I can't see how it is related. There were a couple of form object names with longer than 32 characters in the name of the object and associated variable. These form object were listbox header and footer objects. In these particular cases, there is no reference to them within the code anywhere. I named them to be consistent but no need for any direct control over them so not in the code. Since the forms themselves were not being opened or used during the Syntax Runtime Error I don't believe this naming issue is related. Thanks Kirk. On Sep 11, 2021, at 12:48 AM, Kirk Brooks via 4D_Tech wrote: > Eric, > " In one case, I clicked the Continue button after each successive error > dialog. " > Did you note the method, line number and type of error? That's exactly the > information you need. And - was that on the server or on a client? > > These sorts of problems are incredibly frustrating until you get a handle > on it. But if you are getting error messages there is information there > that will help you. > > On Fri, Sep 10, 2021 at 12:27 PM Eric Asadoorian via 4D_Tech < > [email protected]> wrote: > >> Kirk, >> >> At the moment, I added some additional logging code to the ON ERR CALL >> handler. My first problem is that I don't have any idea what method is >> throwing the error. Unfortunately, it is not occurring often enough. I >> have been dealing with it for about 2 months. Given that it only occurs >> roughly 12 days from a fresh application launch, I haven't experienced >> enough to get a sense of where it is happening. Once the error appears it >> does not necessarily crash the application. In one case, I clicked the >> Continue button after each successive error dialog. The error code remains >> the same. I assumed it was in a for loop, then it just crashed. Another >> time, I kept clicking Continue and it never ended (after 70 times I gave up >> and hit Abort). Therefore, in that instance it was likely in a repeat >> until and the until boolean never went True. These are just guesses. I am >> presently hoping that there will be more information available in a log >> file the next time it occurs. >> >> Thanks for your assistance. >> >> Eric >> On Sep 9, 2021, at 8:20 PM, Kirk Brooks via 4D_Tech wrote: >> >>> Eric, >>> Sounds like some sort of run time error. Most likely caused when some >>> unexpected data type is attempting to be read into an array (one of the >>> arrays managed by a pointer and gets the warning). Running interpreted 4D >>> is very robust as fixing these sort of data type errors but running >>> compiled it throws an error instead. This is why you won't catch it >>> interpreted. >>> >>> If it's consistently happening in a particular method then add more error >>> checking to that method until you figure out what's going on. >>> >>> If it's happening in different methods are these methods managing writing >>> to arrays directly? If so can you write a method to manage that write >>> operation and use this method in all the places the arrays are written >> to? >>> The idea is to get the code that's likely to throw the error in one >> place. >>> >>> Once you figure out what this edge case is you can decide the best way to >>> either protect against it or manage the incoming data to prevent it. >>> >>> On Thu, Sep 9, 2021 at 9:06 AM Eric Asadoorian via 4D_Tech < >>> [email protected]> wrote: >>> >>>> Hello. >>>> >>>> Environment is v17.5 64-Bit in either OS X Sierra or Mojave (latest >>>> versions). The database application does not experience much in the >> way of >>>> user interaction. It is mainly responding to requests over TCP. It >> runs >>>> 24/7. >>>> >>>> Compiler presents no errors, several warnings, but nothing new that >> hasn't >>>> been seen before in earlier versions (v16, v15, back to v13). Warnings >> are >>>> mostly of the sort where pointers are used for arrays and it isn't >> clear if >>>> the data types will be correct at runtime. These methods run often and >>>> have not presented a problem. >>>> >>>> Application can run for anywhere from 6 days to several weeks and no >>>> issues. Then a runtime error will pop up citing Error 48 (I believe >> that >>>> it says Syntax Error when looking at detail in Application Process, but >> not >>>> sure, I will need to take a screenshot next time). >>>> >>>> This has occurred randomly without any real repeatable activity that I >> can >>>> surmise. I decided to let the application run in interpreted mode >> hoping >>>> that the error will surface and I can identify the offending code in the >>>> debugger. So far, nearly 2 weeks in and no error. Therefore, I am >>>> reaching the conclusion that this error will likely only show up in a >>>> compiled database. >>>> >>>> I did not think a Syntax Error could occur in a compiled database. I am >>>> guessing that it is related to a text value being passed to a 4D command >>>> that would not be known in advance. However, I can't find anything >> that is >>>> in error. I checked New Process, Execute on Server, and semaphore >> related >>>> commands thus far. >>>> >>>> Where would be a good place to start looking? Has anyone had such an >>>> experience before? Is there a way to identify more clearly what code is >>>> executing when the error appears? >>>> >>>> Thank you, >>>> Eric Asadoorian >>>> >>>> ********************************************************************** >>>> 4D Internet Users Group (4D iNUG) >>>> New Forum: https://discuss.4D.com >>>> Archive: http://lists.4d.com/archives.html >>>> Options: https://lists.4d.com/mailman/options/4d_tech >>>> Unsub: mailto:[email protected] >>>> ********************************************************************** >>> >>> >>> >>> -- >>> Kirk Brooks >>> San Francisco, CA >>> ====================== >>> ********************************************************************** >>> 4D Internet Users Group (4D iNUG) >>> New Forum: https://discuss.4D.com >>> Archive: http://lists.4d.com/archives.html >>> Options: https://lists.4d.com/mailman/options/4d_tech >>> Unsub: mailto:[email protected] >>> ********************************************************************** >> >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> New Forum: https://discuss.4D.com >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:[email protected] >> ********************************************************************** > > > > -- > Kirk Brooks > San Francisco, CA > ====================== > ********************************************************************** > 4D Internet Users Group (4D iNUG) > New Forum: https://discuss.4D.com > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) New Forum: https://discuss.4D.com Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
