Max execution time error

Management and Administration
1

gutiersa wrote on Tuesday, December 20, 2011:

Hello:

I have what I believe are two identical  openemr-4.1.0_5 installations. One in a windows vista desktop (live), the other in a windows vista laptop (test). I have compared all files and they are same. I have compared httpd.conf, and php.ini and they are the same. Also same version of xampp 1.7.3.
my documents are in:

test server (laptop): /openemr/sites/default/documents

live server (desktop): /openemr/sites/openemr/documents

I am able to open my documents in my laptop (test) but I get the following error when I try to open documents in the desktop (live):

PHP Fatal error:  Maximum execution time of 90 seconds exceeded in C:\xampp\htdocs\openemr\library\classes\Tree.class.php on line 98

this is line 98:

while ($right<$row) {
array_pop($right);
}

Please help, we have not been able to access our documents in like a month. I have even changed servers from freebsd to windows. I wanted to take advantage of using xampp with openemr.

ty
Sandra

2

yehster wrote on Tuesday, December 20, 2011:

Sandra,
It’s hard to diagnose a problem like this remotely.  However, I think the problem is likely related to your document categories. Are the databases the same between the two systems?  I suspect that some how a category “lower” in the document tree somehow refers back to a category higher in the tree and you have an infinite loop as a result.
What does your categories table look like?

Incidentally, I honestly think you are better off staying with a Unix variant rather than going with xampp, but that’s a different discussion.
-Kevin Yeh
kevin.y@integralemr.com

3

gutiersa wrote on Tuesday, December 20, 2011:

Thanks for your reply,

Yes I thought of that so I made the table same as the test table and the problem did not go away. this is what the export looked like in the test machine:
CREATE TABLE IF NOT EXISTS `categories` (
  `id` int(11) NOT NULL DEFAULT ‘0’,
  `name` varchar(255) DEFAULT NULL,
  `value` varchar(255) DEFAULT NULL,
  `parent` int(11) NOT NULL DEFAULT ‘0’,
  `lft` int(11) NOT NULL DEFAULT ‘0’,
  `rght` int(11) NOT NULL DEFAULT ‘0’,
  PRIMARY KEY (`id`),
  KEY `parent` (`parent`),
  KEY `lft` (`lft`,`rght`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • Dumping data for table `categories`

INSERT INTO `categories` (`id`, `name`, `value`, `parent`, `lft`, `rght`) VALUES
(1, ‘Categories’, ‘’, 0, 0, 39),
(2, ‘Lab Report’, ‘’, 1, 1, 2),
(3, ‘Medical Record’, ‘’, 1, 3, 4),
(4, ‘Patient Information’, ‘’, 1, 5, 10),
(5, ‘Patient ID card’, ‘’, 4, 6, 7),
(6, ‘Patient Photograph’, ‘’, 1, 11, 12),
(7, ‘Diagnostics’, ‘’, 1, 13, 14),
(8, ‘Consults’, ‘’, 1, 15, 16),
(9, ‘Correspondence’, ‘’, 1, 17, 18),
(10, ‘Other’, ‘’, 1, 19, 20),
(11, ‘Consents’, ‘’, 4, 8, 9),
(12, ‘Hospital/Old records’, ‘’, 1, 21, 22),
(13, ‘Referrals’, ‘’, 1, 23, 24),
(14, ‘Deleted’, ‘’, 1, 25, 26),
(15, ‘Advance Directive’, ‘’, 1, 27, 34),
(16, ‘Do Not Resuscitate Order’, ‘’, 15, 28, 29),
(17, ‘Durable Power of Attorney’, ‘’, 15, 30, 31),
(18, ‘Living Will’, ‘’, 15, 32, 33),
(19, ‘CCR’, ‘’, 1, 35, 36),
(20, ‘CCD’, ‘’, 1, 37, 38);

this is what it looked like in the production server:

CREATE TABLE IF NOT EXISTS `categories` (
  `id` int(11) NOT NULL DEFAULT ‘0’,
  `name` varchar(255) DEFAULT NULL,
  `value` varchar(255) DEFAULT NULL,
  `parent` int(11) NOT NULL DEFAULT ‘0’,
  `lft` int(11) NOT NULL DEFAULT ‘0’,
  `rght` int(11) NOT NULL DEFAULT ‘0’,
  PRIMARY KEY (`id`),
  KEY `parent` (`parent`),
  KEY `lft` (`lft`,`rght`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • Dumping data for table `categories`

INSERT INTO `categories` (`id`, `name`, `value`, `parent`, `lft`, `rght`) VALUES
(1, ‘Categories’, ‘’, 0, 0, 47),
(2, ‘Lab Report’, ‘’, 1, 1, 2),
(3, ‘Medical Record’, ‘’, 1, 3, 4),
(4, ‘Patient Information’, ‘’, 1, 5, 10),
(5, ‘Patient ID card’, ‘’, 4, 6, 7),
(6, ‘Patient Photograph’, ‘’, 1, 11, 12),
(7, ‘Diagnostics’, ‘’, 1, 13, 14),
(8, ‘Consults’, ‘’, 1, 15, 16),
(9, ‘Correspondence’, ‘’, 1, 17, 18),
(10, ‘Other’, ‘’, 1, 19, 20),
(11, ‘Consents’, ‘’, 4, 8, 9),
(12, ‘Hospital/Old records’, ‘’, 1, 21, 22),
(13, ‘Referrals’, ‘’, 1, 23, 24),
(14, ‘Deleted’, ‘’, 1, 25, 26),
(15, ‘Advance Directive’, ‘’, 1, 27, 34),
(16, ‘Do Not Resuscitate Order’, ‘’, 15, 28, 29),
(17, ‘Durable Power of Attorney’, ‘’, 15, 30, 31),
(18, ‘Living Will’, ‘’, 15, 32, 33),
(19, ‘CCR’, ‘’, 1, 35, 36),
(20, ‘CCD’, ‘’, 1, 37, 38),
(21, ‘Advance Directive’, ‘’, 1, 39, 46),
(22, ‘Advance Directive’, ‘’, 1, 47, 54);

The only difference was the first row in the production server had a 47 for the rght field, and rows 21 and 22 were not present.

I do believe this is a database issue. The test server should have been brought up to date (ie rows 21 and 22 added) when  I updated and patched the database.

Now the production server has a 39 for row 1 field rght, and rows 21 and 22.

Sandra

PS. test server is 64 bit laptop, and production is 32 bit desktop

4

gutiersa wrote on Tuesday, December 20, 2011:

BTW Kevin,

yes I agree with you one hundred percent.
This is intended to be a temporary solution. Since I messed up my server while trying to fix the the documents problem, we had no medical records at all (we have no paper charts) for 2 weeks. I transferred everything to a windows pc. I figured I might as well do a fresh install of the latest stable version of FreeBSD 8 (I had 7), and get more hard drive space for the server. It is an actual HP server as opposed to a desktop.

ty
sandra

5

yehster wrote on Tuesday, December 20, 2011:

Suggest you try deleting rows 21 and 22 completely and seeing if that prevents the loop.
I think that the “47 left” entry on row 22 might “refer back” to the “47 right” entry on row one and be the source of the infinite loop.
My suspicion is that an having an entry appear as both a “right” and a “left” is the cause of the infinite loop.  You seem to have either 39 or 47 doing that to you depending on the current state of your data.

6

yehster wrote on Tuesday, December 20, 2011:

Alternately,
Import the working categories table from your test system into your production system and see if that restores access. That may not be the end result you are looking for, but at least it would be diagnostic.

7

gutiersa wrote on Tuesday, December 20, 2011:

Kevin

Guess what, that is exactly what I was doing. I deleted rows 21 and 22 and that did it. I have been stressing over this for about a month.

Incidentally line 15 already is the Advance directive category, and 21 and 22 are also. This is what is causing the loop.
It must have happened with upgrading the database.

The database upgrade instructions tell u to choose the last version u remember if not sure. But then this entry keeps getting inserted at the end of the table if you are forgetful like I am.

Hopefully with the new admin.php this won’t happen anymore?

thanks a mill.

sandra

8

gutiersa wrote on Tuesday, December 20, 2011:

Oh did I forget to mention that deleting those two rows did the trick?

Sandra

9

yehster wrote on Tuesday, December 20, 2011:

Sandra,
I don’t think the recent admin changes affect this bug. 
The 3-2-0 to 4-0-0 database upgrade looks like the one that added the advanced directive row(s).   

The patch mechanism is supposed to prevent duplication but for whatever reasons it didn’t work for your system.

Not sure the resources are available to figure out the bigger issue right now, but I’m glad you are up and running again.