> I understand your thinking that 4D may not the way to go for event logging, > but your concern about CLOSE DOCUMENT is where we do not agree. I'am sure you > have seen CLOSE DOCUMENT fail, but I suspect that what you are seeing is not > an issue with CLOSE DOCUMENT, but something else not readily apparent. I think > you said at some point that 4D has recognized this as a bug, but I still > question whether in fact it is.
Yes, you're absolutely right on this point. I don't know what the bug is. It *manifests* as an impossible file lock error, but I think it's very, very likely that this is a symptom of something else. Either way, it's a show-stopper for me and I can't fix it. > Perhaps you can show me in the sample database how to make CLOSE DOCUMENT fail > or have another database that demonstrates the problem? That one already shows the problem. I've reproduced it, as has 4D and a couple of other people. Once it happens, you get all kinds of weird stuff - duplicate workers with "unique" names, the runtime monitor gets super buggy and starts throwing range errors...until you're dead. If you *don't* find this result on your gear, please post what version of 4D you're testing with. >> When I saw your initial post in this regard, I jumped in because I do a lot of > work that involves the opening and closing of documents. If a problem exists I > really need to know about it. Thus far my testing based on your posts has not > demonstrated anything that has caused me to doubt that CLOSE DOCUMENT will in > fact close a file. Just try out a compiled version of the original database I sent without any of your modifications and let it run for a couple of minutes. Oh, I forgot to say earlier about John's finding of ~2.1M messages being a kind of breaking point...that number may not be replicable in other tests. You might find a different number. The payloads in my scratch database are quite small. For all I know, if you made the payloads 10x bigger, you would crash with ~210K messages. I won't be testing this myself. On Mon, Oct 9, 2017 at 3:33 AM, John Baughman via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > > On Oct 8, 2017, at 4:42 PM, David Adams via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > > > What I'm concerned about is that CLOSE DOCUMENT may be > > returning without the file *actually* being closed. That's really > > problematic. > > > I understand your thinking that 4D may not the way to go for event > logging, but your concern about CLOSE DOCUMENT is where we do not agree. > I'am sure you have seen CLOSE DOCUMENT fail, but I suspect that what you > are seeing is not an issue with CLOSE DOCUMENT, but something else not > readily apparent. I think you said at some point that 4D has recognized > this as a bug, but I still question whether in fact it is. > > Perhaps you can show me in the sample database how to make CLOSE DOCUMENT > fail or have another database that demonstrates the problem? > > When I saw your initial post in this regard, I jumped in because I do a > lot of work that involves the opening and closing of documents. If a > problem exists I really need to know about it. Thus far my testing based on > your posts has not demonstrated anything that has caused me to doubt that > CLOSE DOCUMENT will in fact close a file. > > John > > > John Baughman > Kailua, Hawaii > (808) 262-0328 > john...@hawaii.rr.com > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** > ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
