Our system was down for a couple of hours today due to one of our users attempting to change a provider’s schedule and entering the following date “2099-12-19” in the “Repeats until” field of the calendar scheduling pop up window. This entry was for category “In Office.”
After the user input the date “2099-12-19”, no one was able to log into OpenEMR-2.8.3. What resulted after entering one’s user name and password was a blank white screen where the calendar should be.
Upon further investigation, I was able to remedy the situation by changing the entry "2099-12-19" in the date field "pc_endDate" in table "openemr_postcalendar_events" to "2009-12-19". Everything was back to normal after correcting this data entry. I am running SUSE Linux Enterprise Server 10 - SP1. My Apache error log is below.
Questions
1.) Why did this generate a fatal error?
2.) Should manual user input into the date field be prohibited to prevent this from happening again? The pop up calendar should suffice for date input from the user.
** APACHE ERROR LOG **
[Tue Jun 10 09:41:42 2008] [error] [client XXX.XXX.X.XXX] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /srv/www/htdocs/openemr-2.8.3/interface/main/calendar/modules/PostCalendar/pnuserapi.php on line 1409, referer: http://XXX.XXX.X.XX/openemr-2.8.3/interface/main/main_info.php
[Tue Jun 10 09:41:49 2008] [error] [client XXX.XXX.X.XXX] PHP Notice: Undefined variable: ignoreAuth in /srv/www/htdocs/openemr-2.8.3/interface/globals.php on line 186, referer: http://XXX.XXX.X.XX/openemr-2.8.3/interface/main/main_navigation.php
The Calendar is not very efficient and takes up a lot of memory. Most likely, to the Calendar, scheduling to “2099-12-19” is about the same as entering scheduling to “infinity”. So I don’t think this was a fatal error so much as it was taking a long time and tying up all the resources.
Clearly, no one in your office is going to live that long. My office extends the schedule about every two years.
Thanks for the input. It was the first time we were down in production since going live and it was quite nerve racking not having the EMR system up and patients in the lobby and phone calls to deal with. The user claimed to have “not done anything” except make a change to the provider’s schedule. I was puzzled that data input for the calendar would have resulted in this error. My last resort would have been to roll back to the previous day’s data.
I noticed that Jason has applied some changes to the calendar. Will it run more efficiently in version 2.8.4? I have not accessed the CVS code ever. I am going to try Brady’s developers appliance soon.
There are some effiencies gained in the CVS code. I narrowed some of the SQL calls so it’s not such a memory hungry beast. However I can still get the system to crash at will. Specifically, it happens when bringing up all of my 150+ providers in the ‘week view’ of the new calendar style. It does OK on the day-view in the new calendar style though.
I’d really like to see the calendar fail gracefully so the entire system doesn’t come crashing down. It’s something on my ‘to-do’ list but nowhere near the top.
I’m very glad to hear that you were able to find and adjust the date value. It can be very frustrating to troubleshoot such a small thing especially when the Apache error log wasn’t very specific.
