| Stefan Ritt wrote: |
| Dan Chitwood wrote: | | We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file? |
Besides the trivial case that people hit the submit button twice I can only imagine one possible cause: If you edit an existing entry, there is a button Resubmit as new entry at the bottom. If that button is checked, the old entry gets deleted and a new one gets submitted. If the delete of the old entry fails for some reason, you could maybe get two entries.
May I suggest following: Use a very simple config file (like the demo one from the distribution) and see if you can reproduce the problem. If not, add you config options one by one to the config file, and see at which option the problem starts. This way you might find the cause of it.
Your problem has not been reported by anybody else so far, so chances are high that it's related to a config setting. |
I was having a very similar problem. After clicking Submit, I was getting dialog box "Submit modified Elog entry?" (with Submit or Cancel options) even though it was a new entry. Whenever I clicked Submit, it added two identical lines (except for ID), but when I clicked Cancel, it added only one entry. This happened in both v2.6.3 and v2.6.5. I eventually deduced it down to the Required Attributes line in the cfg file. I removed almost all other lines and then started removing each required attribute until the field was identified. For some reason it didn't like field name called "Date/Time Reproted" and when I removed it, it added fine, although that one field had to be unrequired when it really should have been req'd. I didn't see anything in the cfg instuctions regarding the use of "/" (unless I missed it) but I assumed it has something to do with that "/". It's interesting to note however that fields by same name under other tabs work fine. It may be bug related. |