1. 

   jcstevens, Member

   I updated my community license and my myDBR version last week (to 4.3.1). I created a duplicate of an existing report and made a few edits to the report code, then I sent the private url out to a handful of users to test. Several users reported back to me that they received the following error when they clicked on the direct url:
   Error 500 - Internal Server Error
   C:\php\php-cgi.exe - The FastCGI process exited unexpectedly
   Module - FastCGIModule
   Notification - ExecuteRequestHandler
   Handler - PHP_via_FastCGI
   Error code - 0x000000ff

   I've received the error myself. Oddly, when I go to my root myDBR path, I can log in and see the reports without error, even via direct url after logging out. However, when I clear my Chrome cache and try to go directly to the report, I get the error.

   I've Googled and sought assistance from my dba and they've attempted to make the following changes but the error persists:
   - Application pool is set to 32-bit enabled
   - All other web applications running on IIS7.5 are working
   - They can't hash the code directly for report.php, so they can't do anything else.

   Since my dba/tech team is out of options, they have asked me to contact myDBR for assistance.
2. 

   jcstevens, Member

   Any ideas on this error? I did not see this FastCGI error ever prior to taking the update to 4.3.1, and to my knowledge nothing else changed. Same IIS7.5 configuration.
3. 

   myDBR Team, Key Master

   If you have error 500 and FastCGI process dying, you most likely have problems with installation (incorrect extension or some other configuration problem). myDBR update could not cause problems like this.

   You should check the server's error logs for more info.

   --
   myDBR Team
4. 

   jcstevens, Member

   The Server error logs show that all other applications are running correctly. No other changes were made to the server or IIS configuration. The only change was to update myDBR from 4.3.0 to 4.3.1 with the license update. My web server admin has told me that he has checked everything that he can and has let me know that it is something with myDBR!

   Is there some way for me to save my reports in myDBR, then run a full uninstall/reinstall to ensure that I have everything correct for the myDBR installation?
5. 

   myDBR Team, Key Master

   If your myDBR installation would be corrupted, you can just run the updater and new fresh version will be installed.

   Alternatively you can just download a new copy. Your reports will be kept intact in the database. If you have made changes under to mydbr/user-directory you want to save those in manual update.

   --
   myDBR Team
6. 

   jcstevens, Member

   I updated the version, but I still get FastCGI exited unexpectedly errors. None of our other php applications running on this webserver are having any issues, and none have ever had this issue. Further, my myDBR installation was running perfectly until I took the update to myDBR 4.3.1. My programmers are unable to troubleshoot myDBR's behavior because your app is heavily hashed, so they can't review the code.

   I'm trying to get my company to purchase the licensing and begin investing in myDBR as our reporting solution, but I need help to resolve this issue or we're done...

   Here are some interesting behaviors with this error:
   

   1. It only happens with unauthenticated users
   2. It only happens when going directly to a report address (assumed in item 1)
   3. The unauthenticated user who experiences this error can go to the root myDBR directory in their browser with 100% success (they can't sign in, of course)
   4. After visiting the root directory, they can go directly to the report link (which previously killed FastCGI) without issue.

   
   These facts indicate that there is a difference between the FastCGI worker thread that starts up from the myDBR root and that which starts up for a myDBR report link. And once a worker thread is started from the root directory, jobs to any child directory appear to be 'fixed'.

   Any ideas of what might cause this?

   Thanks,
   Johnny
7. 

   myDBR Team, Key Master

   When an unautenticated user tried to access a report directly, myDBR will redirect user to the login page and after an successful login, redirects user back to the requested report. So it sounds like your server configuration has problems with a normal redirect.

   There is nothing special in myDBR's redirect, it simply does a redirect to the login page:

   header("Location:index.php?a=login");
   die();

   You can try to simulate the situation by creating a similar page that does a redirect.

   To debug the 500 errors in IIS, set log_errors = off and error_reporting = E_ALL and display_errors = On, so you might get a better error message.

   --
   myDBR Team
8. 

   jcstevens, Member

   Just to clarify, I'm using reports where I have checked the box to allow unauthenticated users to get to the report with the direct url. The users are going to the report url (http://corpappswimp.mysite.com/jcstevens/mydbr/report.php?r=125&m=1&h=98cdaa446f7969f5689b844b71982548f0e8ceff&i=1) and are immediately presented with the 500 Error page. If I send them to the root page (http://corpappswimp.mysite.com/jcstevens/mydbr/) they see the login prompt successfully, but they cannot log in because they don't have defined users. Once they visit the root page, however, they can then go back to the original report link and no longer see the 500 Error (until they try again later in the day, tomorrow, etc).

   Are you saying that, underneath this setup, myDBR automatically redirects an unauthenticated user to the login page, fails, then goes back to the report? If so, then I shouldn't be having this issue as you are saying that myDBR is automatically doing the workaround that I'm having users do. Am I misunderstanding what you said?
9. 

   myDBR Team, Key Master

   If you have checked "Access without login allowed via direct URL", then no redirect happens.

   Is this happening with any report or is it specific to a certain report / functionality in a report?

   If you delete the myDBR cookie from the browser (mydbr-id), does the crash still happen when accessing the report directly?

   --
   myDBR
10. 

    jcstevens, Member

    That's correct. I have that box checked.

    I have only 3 reports in production and it has happened sporadically on each of them, before presenting the first screen with user parameters. To my knowledge, it hasn't happened after the user enters parameters and clicks to execute the report.

    I have cleared my cache completely and had this happen on my client.

    This has not happened with 'named' users because they have to go through the login first (the page which acts as a workaround fix for unauthenticated users).
11. 

    jcstevens, Member

    Any update on this? I'd really like to see myDBR as our marquis reporting tools but I can't sell it to my management if there are sporadic issues like this. I'm ready to work with whomever can help resolve this issue.
12. 

    myDBR Team, Key Master

    Could you try the latest build?

    --
    myDBR Team
13. 

    jcstevens, Member

    I took the update yesterday to build 2526. I'll continue testing.
14. 

    myDBR Team, Key Master

    Update to build 2527 instead. We've updated some components there that could be related to this issue.

    --
    myDBR Team
15. 

    jcstevens, Member

    done. I'm now at 2527.

Reply

You must log in to post.