Re: [SL] Apache error running summary reports - reality checking script?

[Michael H. <mh...@it...>]

Based on the advice to check dates I've just been through every date  
value of every record of every table, and I found a couple of bogus  
dates, (you'd think bounds checking would catch '08-27-0200'), and  
fixed them, but still no go.
    I also checked to see if maybe the version upgrade had missed a  
file due to permissions or something but all the .pl files are the  
same date and perms, (except setup.pl is a few days newer but that's  
to be expected and shouldn't matter).
    What other things should we be checking?
    Mismatches between invoices and line items, (e.g. line items  
without invoices)?

<rant>
    I'm really surprised there are no scripts already written for  
this.  I actually was a rocket scientist, ahem, database programmer,  
in a past life and every project I ever worked on had an "admin  
toolkit" by the end of it with various queries to be sure nothing  
bizarre had slipped through the cracks.  This wasn't intentional, but  
all db programmers end up doing some "pre-QA" of their own and the  
scripts just grow naturally from that.
</rant>

    Anyway, again, suggestions would be greatly appreciated from  
anyone who has dealt with anything like this before...?


Thanks!!!!

Michael



On Jul 3, 2008, at 4:06 AM, ja...@in... wrote:

>  A simple sanity check that I wish I had time to implement is to
> regularly (cron job) :
>  Check each company in the database and hunt for any transactions
> with illogical (ie stupid) dates
>  such as 07/03/2080 (transposed year digits)
>  Send informative email to user who entered the offending
> transaction, and copy to sysadmin.
>  Still hoping Dieter might implement something sensible in company
> defaults to solve this simple problem.
>  Been mentioned before.
>  Very interested in any other sanity checks.
>  DJ
>  On Thu 03/07/08  3:21 PM , Michael Hasse mh...@it... sent:
>  Months later, I'm getting back to this, (prodded by tax deadlines of
>
>  course!  :)
>      I did check the timeout directive and raised it to some
>  ridiculous level to no avail, (and same duration of wait so I don't
>
>  think that's it).
>      Also don't think it's a record count issue as it was working
> fine
>  right up a month or two before the upgrade and we don't do THAT much
>
>  business.
>      I also opened a terminal session to the host server and watched
>
>  the stats as it was running and there were no issues with
> memory/swap/
>  etc running out or anything like that.
>      Somebody suggested checking another company in the system, (good
>
>  idea, my apologies for not doing that before posting!  Brain
> fade...).
>      Unfortunately that company works just fine so I have to assume
> at
>  this point that I have a corrupt record somewhere/somehow.
>      So now the question is - are there any sort of scripts that can
>
>  be run to do a sanity check?  Has anybody had to deal with bad
>  records and might have some tips to save a few hours of poring over
>
>  the DB structure?
>  Thanks!!!!!!!!!!!!
>  Michael
>  On Jan 8, 2008, at 6:01 AM, William McKee wrote:
>> On Mon, Jan 07, 2008 at 09:34:39PM -0800, Michael Hasse wrote:
>>> Just an update on this.  Permissions are all fine and the reports
> run
>>> with no problems in our test company.  Reading up a bit on the
> errors
>>> it looks like a simple timeout problem where Apache is giving up
> on
>>> the script before it finishes due to the amount of data we have
>>> slowing the script down.  (System resources are okay so we're not
>
>>> running out of memory or anything).
>>
>> Interesting, I hadn't considered timeout error causing that
> message.
>>
>>
>>>     Suggestions/advice are welcome and we'll keep plugging away
> at it
>>> and post back if we figure it out.
>>
>> Have you checked out the TimeOut directive[1]? I've seen some
> people
>> comment the TimeOut does not affect CGI scripts, but Apache
> security
>> tips[2] say the following:
>>
>>  "As TimeOut is currently used for several different operations,
>
>> setting
>>  it to a low value introduces problems with long running CGI
> scripts."
>>
>> I've seen others suggest using FastCGI. Keep us posted on your
>> progress.
>>
>>
>> Good luck,
>> William
>>
> ---------------------------------------------------------------------- 
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users