Neil: Go through your code and make sure there are no indirect object references like $obj->obj->func();
>From what i understand, it seems that this type of construction is causing a temporary object to be left around (which is, in turn, causing excel to remain zombie, becuase the temp-object is never properly cleaned up) Anyone with knowledge of COM... is this intended behaviour? Do COM objects *need* a Quit() signal to die, even if the program that was manipulating the COM object dies (as is the case with PHP finishing up and EXCEL still in memory when a temp-object is not properly unset())? --- Scott Hurring Systems Programmer EAC Corporation [EMAIL PROTECTED] Voice: 201-462-2149 Fax: 201-288-1515 > -----Original Message----- > From: Neil Lincoln [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 9:23 AM > To: Alan Brown; Scott Hurring; Php-Win (E-mail) > Subject: RE: [PHP-WIN] Excel not closing after using it via COM > > > We have tried this and it doesn't help. And yes, any non > normal exit from > the EXCEL COM object results in a "zombie". > > -----Original Message----- > From: Alan Brown [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 8:00 AM > To: Scott Hurring; Php-Win (E-mail) > Subject: Re: [PHP-WIN] Excel not closing after using it via COM > > There is a missing "Release" call in the COM code when > temporary objects are > created for a construct such as > > $excel->application->DisplayAlerts = False; > > This is not as visible a problem with an inproc server as > with a localserver > such as Excel. > > It is fairly easy to work around this (until I get a real fix > into the base) > by breaking it up thus: > > $application = $excel->application; > $application->DisplayAlerts = False; > > This has to be done in two places in the example I saw. > However I note that > if you put in a logic error such as this: > $book = $workbooks->Open($file); > $sheet = $books->Worksheets(1); > > After the exception a copy of Excel is still left running. I > wiill look more > at this over the weekend and test my Release() call on the > temporary object. > It seems to work, but I fear that it will break something else.... > > Alan. > > ----- Original Message ----- > From: "Scott Hurring" <[EMAIL PROTECTED]> > To: "Php-Win (E-mail)" <[EMAIL PROTECTED]> > Sent: Thursday, 25 April, 2002 13:51 > Subject: RE: [PHP-WIN] Excel not closing after using it via COM > > > > I'm not doing this through Apache. > > > > I tried out Win32 command line PHP and Perl. > > > > So even though it might be an issue with Excel being > > owned by "SYSTEM" when run thru Apache, PHP still leaves > > it open whereas Perl does not. > > > > (And to boot, my Apache service is configured to > > RunAs my account "scott", so it shouldn't be plauged > > by the "SYSTEM" ownership issue... even though > > i haven't tested it) > > > > Please check out: http://furt.com/code/php/com_issues/ > > (Read 'readme.txt') > > > > --- > > Scott Hurring > > Systems Programmer > > EAC Corporation > > [EMAIL PROTECTED] > > Voice: 201-462-2149 > > Fax: 201-288-1515 > > > > > -----Original Message----- > > > From: Neil Lincoln [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, April 25, 2002 1:20 PM > > > To: Scott Hurring; Php-Win (E-mail) > > > Subject: RE: [PHP-WIN] Excel not closing after using it via COM > > > > > > > > > On our systems the EXCEL COM object executes as a member of > > > "SYSTEM" instead > > > of as a child of the owner of the Apache/php server. When the > > > COM object > > > completes it leaves the EXCEL hanging around as a child of a > > > SYSTEM process. > > > > > > -----Original Message----- > > > From: Scott Hurring [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, April 25, 2002 11:59 AM > > > To: Php-Win (E-mail) > > > Subject: RE: [PHP-WIN] Excel not closing after using it via COM > > > > > > I went back and ran some perl code using the > > > Excel COM object. Excel does properly exit... > > > so it looks like you are correct -- it's > > > probably a bug in PHP's COM code. > > > > > > Attached is is sample Perl, PHP and Excel, > > > if anyone wants to verify that excel does > > > indeed die after the perl script is finished, > > > yet stays alive when the PHP script is > > > finished. > > > > > > --- > > > Scott Hurring > > > Systems Programmer > > > EAC Corporation > > > [EMAIL PROTECTED] > > > Voice: 201-462-2149 > > > Fax: 201-288-1515 > > > > > > > -----Original Message----- > > > > Try > > > > > > > > $book->Close("False"); > > > > > > > > > > Doesnt do anything. > > > > > > > But then one has to ask, why does it work fine from other > > > > languages, e.g. Perl? If the API were broken, it would seem > > > > that it would be broken regardless of the language one was > > > > using. > > > > > > > > Scott > > > > > > Yeah.. that's the way it seems now. > > > > > > > > > --- > > > Incoming mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 > > > > > > > > > > -- > > PHP Windows Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > PHP Windows Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 > > -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
