sql-ledger-users — SQL-Ledger users

[SL] postgresql 8.3

[david <da...@ke...>]

I'm thinking of migrating sql-ledger from 2.6.27 / postgresql 8.1 to
2.8.16 / postgresql 8.3

Are there any migration issues during the transition? In other words,
will the pg-dump from SL 2.6.27 / pg 8.1 talk nicely to pg 8.3? Or do I
have to upgrade via pg 8.1, and the go to pg 8.3 at the last step?

thanks


David.

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

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

Just thought I'd post the final resolution to this.
    Hadn't gotten it over to a VM yet but needed the reports working  
asap so I first updated to the latest and greatest SL, which didn't  
fix it, so then I just did a "yum update", did the postgresql 8  
upgrade shuffle and hey presto!  Reports run instantly like they used  
to!


Thanks to all!!!!!!!!

Michael


On Jul 21, 2008, at 10:42 AM, Michael Hasse wrote:

> All valid points except that "top" shows CPU/RAM to be just fine
> while the report is running, as is disk/swap.
>     This is an older machine, our last non-virtual system, actually,
> so maybe we'll just go ahead and do the VM migration and see what
> happens.
>
>
> Thanks,
>
> Michael
>
> On Jul 21, 2008, at 8:59 AM, Paul Tammes wrote:
>
>> Seeing FC4 where 9 is out, postgresql 7.4 where 8.x is out, could
>> it be the
>> hardware is old as well?
>> I know, if it ain't broke and all that ;-)
>>
>> If the hardware is not up to speed for a larger number of months,
>> memory
>> overflow combined with swapping to (slow/old/olmost dead?) Harddisk
>> comes to
>> mind. The change in response between say an AMD Duron 800 and AMD
>> 4450e
>> dualcore is stunning.
>> Both el cheapo cpu but frome different era's alltogether: in
>> hardware 8
>> years is a lifetime and a halve.
>> Nice part: the power consumption of some modern cpu's like 4450e
>> ore dulcore
>> intels is stunningly lower.
>> So that kind of investment earns itself in a few years time as well.
>>
>> (If that is too much of an investment, try adding some extra memory
>> to the
>> old box.
>> SD-ram is still available in some antique shops, or second hand on
>> computer
>> user club trade fairs.
>> DDR (sec) is more readilly available, and other than SD-ram (which
>> is rare,
>> therefore expensive) pretty cheap as well
>>
>> Hth
>>
>> 2008/7/21 Michael Hasse <mh...@it...>:
>>
>>> Further testing shows that it is indeed something timing out.  The
>>> reason the test company report ran okay was because there were  
>>> hardly
>>> any records.  I am also able to run the problem reports okay  
>>> provided
>>> I choose only a month or two range.  Having run the reports for
>>> successive months of the entire year with no problems we can at  
>>> least
>>> get the taxes taken care of, (whew! :), and short of some bizarre
>>> boundary error this should prove that the data is okay.
>>>
>>>    But the question remains of what exactly it is that is timing
>>> out...?
>>>
>>>    In the process of testing this it looks like we actually get any
>>> of a variety of errors, some of them pretty generic, e.g. plain old
>>> Apache "Internal server error".
>>>    (William's suggestions earlier unfortunately did not pan out.)
>>>
>>>    This is an FC4 box running:
>>>        Apache 2.0.54 w/mod_perl 2.0.1
>>>        Postgresql 7.4.13
>>>        Perl 5.8.6
>>>
>>> Any ideas?
>>>
>>>
>>> Thanks!
>>>
>>> Michael
>>>
>>>
>>> ================================
>>> 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
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> ---
>>> -
>>> 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
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> ----
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> sql-ledger-users mailing list
>>> sql...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>>>
>>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Can't send email

[Danita Z. <da...@ca...>]

Actually, this was on a LUM enabled OES server, and something was up
with LDAP - it's all fixed now!

Thanks anyway!

Danita

 
>>> "Danita Zanre" <da...@ca...> 7/21/2008 4:57 PM >>> 
So, my SQL-Ledger server has been working pretty well for a couple of
years.  Just today i tried to send a quotation, and I get this in my
postfix log:

fatal: no login name found for user ID 30

This just started happening.  I sent invoices out on July 11 with no
problems.

Any idea what's causing this all of a sudden?

Thanks.

Danita



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
sql-ledger-users mailing list
sql...@li...
https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] Error SL/Form.pl

[Giedrius <zl...@nk...>]

On Tue, 15 Jul 2008 07:44:31 -0700
Bob Miller <bo...@co...> wrote:

> Giedrius:
> Check here, the top post:
> http://abacus.sql-ledger.com/userforum/forum.php
> 
I installed perl 5.8.8 from source, but without success.
Additionally, the new problem appeared - while posting a sales order I
get the following:

Error!

Can't locate version/vxs.pm in @INC (@INC
contains: /usr/local/lib/perl5/5.8.8/i686-linux /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/i686-linux /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl .)
at (eval 11) line 2.

Thanks in advance,

-- 
Giedrius

[SL] Can't send email

[Danita Z. <da...@ca...>]

So, my SQL-Ledger server has been working pretty well for a couple of
years.  Just today i tried to send a quotation, and I get this in my
postfix log:

fatal: no login name found for user ID 30

This just started happening.  I sent invoices out on July 11 with no
problems.

Any idea what's causing this all of a sudden?

Thanks.

Danita

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

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

All valid points except that "top" shows CPU/RAM to be just fine  
while the report is running, as is disk/swap.
    This is an older machine, our last non-virtual system, actually,  
so maybe we'll just go ahead and do the VM migration and see what  
happens.


Thanks,

Michael

On Jul 21, 2008, at 8:59 AM, Paul Tammes wrote:

> Seeing FC4 where 9 is out, postgresql 7.4 where 8.x is out, could  
> it be the
> hardware is old as well?
> I know, if it ain't broke and all that ;-)
>
> If the hardware is not up to speed for a larger number of months,  
> memory
> overflow combined with swapping to (slow/old/olmost dead?) Harddisk  
> comes to
> mind. The change in response between say an AMD Duron 800 and AMD  
> 4450e
> dualcore is stunning.
> Both el cheapo cpu but frome different era's alltogether: in  
> hardware 8
> years is a lifetime and a halve.
> Nice part: the power consumption of some modern cpu's like 4450e  
> ore dulcore
> intels is stunningly lower.
> So that kind of investment earns itself in a few years time as well.
>
> (If that is too much of an investment, try adding some extra memory  
> to the
> old box.
> SD-ram is still available in some antique shops, or second hand on  
> computer
> user club trade fairs.
> DDR (sec) is more readilly available, and other than SD-ram (which  
> is rare,
> therefore expensive) pretty cheap as well
>
> Hth
>
> 2008/7/21 Michael Hasse <mh...@it...>:
>
>> Further testing shows that it is indeed something timing out.  The
>> reason the test company report ran okay was because there were hardly
>> any records.  I am also able to run the problem reports okay provided
>> I choose only a month or two range.  Having run the reports for
>> successive months of the entire year with no problems we can at least
>> get the taxes taken care of, (whew! :), and short of some bizarre
>> boundary error this should prove that the data is okay.
>>
>>    But the question remains of what exactly it is that is timing
>> out...?
>>
>>    In the process of testing this it looks like we actually get any
>> of a variety of errors, some of them pretty generic, e.g. plain old
>> Apache "Internal server error".
>>    (William's suggestions earlier unfortunately did not pan out.)
>>
>>    This is an FC4 box running:
>>        Apache 2.0.54 w/mod_perl 2.0.1
>>        Postgresql 7.4.13
>>        Perl 5.8.6
>>
>> Any ideas?
>>
>>
>> Thanks!
>>
>> Michael
>>
>>
>> ================================
>> 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
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> -
>> 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
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> sql-ledger-users mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>>
>>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

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

[Paul T. <pt...@wa...>]

Seeing FC4 where 9 is out, postgresql 7.4 where 8.x is out, could it be the
hardware is old as well?
I know, if it ain't broke and all that ;-)

If the hardware is not up to speed for a larger number of months, memory
overflow combined with swapping to (slow/old/olmost dead?) Harddisk comes to
mind. The change in response between say an AMD Duron 800 and AMD 4450e
dualcore is stunning.
Both el cheapo cpu but frome different era's alltogether: in hardware 8
years is a lifetime and a halve.
Nice part: the power consumption of some modern cpu's like 4450e ore dulcore
intels is stunningly lower.
So that kind of investment earns itself in a few years time as well.

(If that is too much of an investment, try adding some extra memory to the
old box.
SD-ram is still available in some antique shops, or second hand on computer
user club trade fairs.
DDR (sec) is more readilly available, and other than SD-ram (which is rare,
therefore expensive) pretty cheap as well

Hth

2008/7/21 Michael Hasse <mh...@it...>:

> Further testing shows that it is indeed something timing out.  The
> reason the test company report ran okay was because there were hardly
> any records.  I am also able to run the problem reports okay provided
> I choose only a month or two range.  Having run the reports for
> successive months of the entire year with no problems we can at least
> get the taxes taken care of, (whew! :), and short of some bizarre
> boundary error this should prove that the data is okay.
>
>    But the question remains of what exactly it is that is timing
> out...?
>
>    In the process of testing this it looks like we actually get any
> of a variety of errors, some of them pretty generic, e.g. plain old
> Apache "Internal server error".
>    (William's suggestions earlier unfortunately did not pan out.)
>
>    This is an FC4 box running:
>        Apache 2.0.54 w/mod_perl 2.0.1
>        Postgresql 7.4.13
>        Perl 5.8.6
>
> Any ideas?
>
>
> Thanks!
>
> Michael
>
>
> ================================
> 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
>
>
> ------------------------------------------------------------------------
> -
> 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
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
>

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

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

Further testing shows that it is indeed something timing out.  The  
reason the test company report ran okay was because there were hardly  
any records.  I am also able to run the problem reports okay provided  
I choose only a month or two range.  Having run the reports for  
successive months of the entire year with no problems we can at least  
get the taxes taken care of, (whew! :), and short of some bizarre  
boundary error this should prove that the data is okay.

    But the question remains of what exactly it is that is timing  
out...?

    In the process of testing this it looks like we actually get any  
of a variety of errors, some of them pretty generic, e.g. plain old  
Apache "Internal server error".
    (William's suggestions earlier unfortunately did not pan out.)

    This is an FC4 box running:
	Apache 2.0.54 w/mod_perl 2.0.1
	Postgresql 7.4.13
	Perl 5.8.6

Any ideas?


Thanks!

Michael


================================
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


------------------------------------------------------------------------ 
-
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

Re: [SL] Error SL/Form.pl

[Bob M. <bo...@co...>]

Giedrius:
Check here, the top post:
http://abacus.sql-ledger.com/userforum/forum.php

-----Original Message-----
From: Giedrius <zl...@nk...>
Reply-To: sql...@li...
To: sql...@li...
Subject: Re: [SL] Error SL/Form.pl
Date: Tue, 15 Jul 2008 17:34:09 +0300


On Sat, 12 Jul 2008 11:55:07 +0300
Giedrius <zl...@nk...> wrote:

> On Wed, 18 Jun 2008 16:57:19 +1000
> Adrian <adr...@ie...> wrote:
> 
> > While printing a purchase order I get the following:
> > 
> > 
> > 
> > Bizarre copy of UNKNOWN in sassign at SL/Form.pm line 984.
> > 
> > Item 	Number 	Description 	Qt'y
> > 	Price 	% 	Amount 1. 	CAD240
> > Battery, hi-cap, AA tagged 	2 		5.50
> > 		11.00 31/01/2009. 	mp9012 	MP3 player
> > black 	1 		129.50 		129.50
> > 01/01/2009. 	NEOCD30 	Fountek NeoCD3.0 ribbon tweeter
> > pair 	1 		149.00 		149.00
> > 
> > Note the item numbers after the first have dates and not item
> > numbers, and that date is also bizarre.
> > 
> > A similar in printing from Accounts Receivable
> > 
> > I am using SQL-Ledger 2.8.14.
> > 
> > I have recently upgraded the postgres.
> > 
> 
> Hmm.... I get the following:
> 
> Error!
> 
> panic: attempt to copy freed scalar 8a04380 to 8233c08 at SL/Form.pm
> line 984.
> 
> Iam using SQL-Ledger 2.8.16 and postgresql 8.0.
> 

Is there any fix or workaround to this bug? I think he is related to
perl 5.10...


Bob Miller
334-7117/633-3760
http://computerisms.ca
bo...@co...
Network, Internet, Server,
and Open Source Solutions

Re: [SL] Error SL/Form.pl

[Giedrius <zl...@nk...>]

On Sat, 12 Jul 2008 11:55:07 +0300
Giedrius <zl...@nk...> wrote:

> On Wed, 18 Jun 2008 16:57:19 +1000
> Adrian <adr...@ie...> wrote:
> 
> > While printing a purchase order I get the following:
> > 
> > 
> > 
> > Bizarre copy of UNKNOWN in sassign at SL/Form.pm line 984.
> > 
> > Item 	Number 	Description 	Qt'y
> > 	Price 	% 	Amount 1. 	CAD240
> > Battery, hi-cap, AA tagged 	2 		5.50
> > 		11.00 31/01/2009. 	mp9012 	MP3 player
> > black 	1 		129.50 		129.50
> > 01/01/2009. 	NEOCD30 	Fountek NeoCD3.0 ribbon tweeter
> > pair 	1 		149.00 		149.00
> > 
> > Note the item numbers after the first have dates and not item
> > numbers, and that date is also bizarre.
> > 
> > A similar in printing from Accounts Receivable
> > 
> > I am using SQL-Ledger 2.8.14.
> > 
> > I have recently upgraded the postgres.
> > 
> 
> Hmm.... I get the following:
> 
> Error!
> 
> panic: attempt to copy freed scalar 8a04380 to 8233c08 at SL/Form.pm
> line 984.
> 
> Iam using SQL-Ledger 2.8.16 and postgresql 8.0.
> 

Is there any fix or workaround to this bug? I think he is related to
perl 5.10...

-- 
Giedrius

[SL] Batch email invoice not recording

[Munroe S. <so...@di...>]

It seems that when sending a batch of emails, there is not a record kept
in the internal notes that the invoice was emailed.

-- 
Munroe Sollog
Systems Engineer
Digirati Consulting, Inc
so...@di...

Re: [SL] Error SL/Form.pl

[Giedrius <zl...@nk...>]

On Wed, 18 Jun 2008 16:57:19 +1000
Adrian <adr...@ie...> wrote:

> While printing a purchase order I get the following:
> 
> 
> 
> Bizarre copy of UNKNOWN in sassign at SL/Form.pm line 984.
> 
> Item 	Number 	Description 	Qt'y
> 	Price 	% 	Amount 1. 	CAD240
> Battery, hi-cap, AA tagged 	2 		5.50
> 		11.00 31/01/2009. 	mp9012 	MP3 player
> black 	1 		129.50 		129.50
> 01/01/2009. 	NEOCD30 	Fountek NeoCD3.0 ribbon tweeter
> pair 	1 		149.00 		149.00
> 
> Note the item numbers after the first have dates and not item
> numbers, and that date is also bizarre.
> 
> A similar in printing from Accounts Receivable
> 
> I am using SQL-Ledger 2.8.14.
> 
> I have recently upgraded the postgres.
> 

Hmm.... I get the following:

Error!

panic: attempt to copy freed scalar 8a04380 to 8233c08 at SL/Form.pm
line 984.

Iam using SQL-Ledger 2.8.16 and postgresql 8.0.

-- 
Giedrius

[SL] reconciliation

[George O. <geo...@ya...>]

Anyone knows how this is supposed to be working?

I had this problem some time ago then it disappeared and now I have it again:
I am trying to reconcile my accounts. I check all transactions. The balance is 
$0.00. I press "DONE" The screen goes back to date selection. I try to select 
a later date and no matter what I do I always get all transactions from the 
beginning of the books. The bottom date limit is always ignored. Here is an 
example:

If your books start from 01.01.2003.
You select dates to reconcile from 01.01.2006 - 31.12.2007.
You get all transactions from 01.01.2003 - 31.12.2007.

I also tested this on a test sever and it works the same way there.


-- 
George
AUSTRALIA
http://www.okstudio.com.au

Re: [SL] 2.6.22 -> 2.8.15 upgrade error

[Bob G. <bo...@rc...>]

I would guess that both symptoms come from trying to reload a database
that already contains your data. You MUST have a created EMPTY
sql-ledger database before doing the restore.

After you have a decent dump of your database (check that it does not
contain the duplicate statements you mention in your email).

The script I use is:
# To restore, do
su  postgres

  psql template1
  psql> DROP DATABASE "sql-ledger";
  psql> CREATE DATABASE "sql-ledger";
  psql> \q

# Then:
psql sql-ledger < sql-ledger.dump

On Sun, 2008-06-29 at 21:33 -0500, Stuart Luppescu wrote:
> On 日, 2008-06-29 at 19:25 -0500, Stuart Luppescu wrote:
> > On 日, 2008-06-22 at 13:50 +0200, Rolf Stöckli wrote:
> > > It seems your database already contains a table "cargo". You should find 
> > > it somewhere in your dump file.
> > > 1) Make a backup.
> > > 2) Insert at the beginning of sql/Pg-upgrade-2.7.0-2.7.5.sql:
> > > 
> > > drop table if exists cargo;
> > > 
> > > 3) Try again to upgrade.
> > > 
> > > Stuart Luppescu schrieb:
> > > > Error!
> > > > create table cargo (id int not null, trans_id int not null, package
> > > > text, netweight float4, grossweight float4, volume float4)
> > > > ERROR: relation "cargo" already exists
> > 
> > Rolf, I entered that line, but got this error:
> > 
> > Error!
> > drop table if exists cargo
> > ERROR: syntax error at or near "exists" at character 15
> > 
> > Right after that is the line that creates the cargo relation. Perhaps I
> > should try and comment out that line...
> 
> So, I commented out the line, unlocked the database, logged in again,
> found another offending line. Repeated this pattern perhaps 100 times. I
> finally got to the point where the upgrade scripts would run to
> completion. Hooray! I now have a functioning 2.8.15 system. 
> 
> However, when I do (AR|AP) -> Reports -> Transactions and select
> ``Details'' all the lines display twice. Has anyone ever seen this
> before?
> 

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

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

[<ja...@in...>]

 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 
 > 

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

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

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
>
> [1] http://httpd.apache.org/docs/2.0/mod/core.html#timeout
> [2] http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos
>
> -- 
> Knowmad Technologies - Web Site Development & Programming
> W: http://www.knowmad.com | E: wi...@kn...
> P: 704.343.9330 | http://www.LinkedIn.com/in/williammckee
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ 
> marketplace
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] 2.6.22 -> 2.8.15 upgrade error

[Stuart L. <sl...@cc...>]

On 日, 2008-06-29 at 19:25 -0500, Stuart Luppescu wrote:
> On 日, 2008-06-22 at 13:50 +0200, Rolf Stöckli wrote:
> > It seems your database already contains a table "cargo". You should find 
> > it somewhere in your dump file.
> > 1) Make a backup.
> > 2) Insert at the beginning of sql/Pg-upgrade-2.7.0-2.7.5.sql:
> > 
> > drop table if exists cargo;
> > 
> > 3) Try again to upgrade.
> > 
> > Stuart Luppescu schrieb:
> > > Error!
> > > create table cargo (id int not null, trans_id int not null, package
> > > text, netweight float4, grossweight float4, volume float4)
> > > ERROR: relation "cargo" already exists
> 
> Rolf, I entered that line, but got this error:
> 
> Error!
> drop table if exists cargo
> ERROR: syntax error at or near "exists" at character 15
> 
> Right after that is the line that creates the cargo relation. Perhaps I
> should try and comment out that line...

So, I commented out the line, unlocked the database, logged in again,
found another offending line. Repeated this pattern perhaps 100 times. I
finally got to the point where the upgrade scripts would run to
completion. Hooray! I now have a functioning 2.8.15 system. 

However, when I do (AR|AP) -> Reports -> Transactions and select
``Details'' all the lines display twice. Has anyone ever seen this
before?

-- 
Stuart Luppescu -=- s-luppescu .at. uchicago.edu        
University of Chicago (^_^)/ CCSR 
才文と智奈美の父 -=-=- Kernel 2.6.23-gentoo-r
You're a card which will have to be dealt with. 
 
 
 
 

Re: [SL] 2.6.22 -> 2.8.15 upgrade error

[Stuart L. <sl...@cc...>]

On 日, 2008-06-22 at 13:50 +0200, Rolf Stöckli wrote:
> It seems your database already contains a table "cargo". You should find 
> it somewhere in your dump file.
> 1) Make a backup.
> 2) Insert at the beginning of sql/Pg-upgrade-2.7.0-2.7.5.sql:
> 
> drop table if exists cargo;
> 
> 3) Try again to upgrade.
> 
> Stuart Luppescu schrieb:
> > Error!
> > create table cargo (id int not null, trans_id int not null, package
> > text, netweight float4, grossweight float4, volume float4)
> > ERROR: relation "cargo" already exists

Rolf, I entered that line, but got this error:

Error!
drop table if exists cargo
ERROR: syntax error at or near "exists" at character 15

Right after that is the line that creates the cargo relation. Perhaps I
should try and comment out that line...

-- 
Stuart Luppescu -=- s-luppescu .at. uchicago.edu        
University of Chicago (^_^)/ CCSR 
才文と智奈美の父 -=-=- Kernel 2.6.23-gentoo-r
<gholam> well I'm impressed <gholam> win98 managed
 to crash X from within vmware. * gholam applauds. 
 
 
 

Re: [SL] need help with TeX

[Myk R. <myk...@gm...>]

That seems to have done the trick, thank you!

On Thursday 26 June 2008 05:59:23 pm Br Nicholas Thirkettle wrote:
> I'm not positive this will work, but your bottom margin is set at -0.5in
> which is half an inch below the bottom of the page (I think). We have
> ours set at 2cm and it works fine. Why don't you just try to set it at
> 0.5in and see if it works. Good luck.
>
> Br. Nicholas
>
>
> Nicholas Thirkettle, OSB
> Saint Joseph's Monastery
> Natchez, Mississippi
>
> On Thu, 2008-06-26 at 13:16 -0500, Myk Robinson wrote:
> > Hey-
> >
> > I am having trouble with my Vendor Invoice Template. The payments trail
> > off the bottom edge of the page. I need some help properly setting up
> > this document for 8.5" x 11" US Letter-sized paper. I don't understand
> > TeX enough to do this. I have made a few adjustments, but cannot find the
> > right one to get the payment data moved up more.
> >
> > Help?
> >
> > YOu may view the document here:
> >
> > http://pastebin.ca/1056580
> >
> > Thanks,
> > -myk
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > sql-ledger-users mailing list
> > sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

Re: [SL] need help with TeX

[Br N. T. <brn...@os...>]

I'm not positive this will work, but your bottom margin is set at -0.5in
which is half an inch below the bottom of the page (I think). We have
ours set at 2cm and it works fine. Why don't you just try to set it at
0.5in and see if it works. Good luck.

Br. Nicholas


Nicholas Thirkettle, OSB
Saint Joseph's Monastery
Natchez, Mississippi


On Thu, 2008-06-26 at 13:16 -0500, Myk Robinson wrote:
> Hey-
> 
> I am having trouble with my Vendor Invoice Template. The payments trail off 
> the bottom edge of the page. I need some help properly setting up this 
> document for 8.5" x 11" US Letter-sized paper. I don't understand TeX enough 
> to do this. I have made a few adjustments, but cannot find the right one to 
> get the payment data moved up more.
> 
> Help?
> 
> YOu may view the document here:
> 
> http://pastebin.ca/1056580
> 
> Thanks,
> -myk
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users
> 

Re: [SL] need help with TeX

[William M. <wi...@kn...>]

Hi Myk,

It takes me at least 30 minutes each time I dive in to update the TeX
templates. I took a quick look at yours but can't provide much input as
I'm a TeX newbie. The best I can do is let you see mine which I have
customized.

I had similar layout problems along the way. Here are my notes on
debugging the templates:

    * Invoice.tex
      If you edit the columns shown, be sure to edit BOTH headers–there
      is one in the main body as well as in the pagebreak section which is
      used for page 2+.
    * Output files are kept in the users directory (e.g.,
      /usr/local/sql-ledger/users) and are preceded by the unix
      timestamp so you can find your most recent attempt by finding the
      highest numbered file. The following extensions are created:
          o .tex - contains the parsed LaTeX file
          o .err - LaTeX error messages
          o .log - LaTeX log messages
          o .aux - nothing useful
    * "Underfull \hbox (badness 10000) in paragraph nn"
          o This message results from SQL-Ledger putting in extra
          \newline's in the description. Latex is complaining about
          these.

I have lots more notes on editing the TeX templates which I could share
as well. I don't want to paste them in here and spam the list so contact
me if you'd like a copy.


Good luck,
William

-- 
Knowmad Technologies - Open Source Software Solutions
W: http://www.knowmad.com | E: wi...@kn...
P: 704.343.9330 | http://www.LinkedIn.com/in/williammckee

Re: [SL] need help with TeX

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

Been a long time since we messed with that, but as I recall we  
actually had to tweak the perl on the back end to get it working  
right.  There was a missing slash or something and our changes to the  
Tex in the editor didn't work until we fixed the code that was using  
it.  That was on a much older version of SL though.  Just throwing it  
out there...


Thanks,

Michael


On Jun 26, 2008, at 11:16 AM, Myk Robinson wrote:

> Hey-
>
> I am having trouble with my Vendor Invoice Template. The payments  
> trail off
> the bottom edge of the page. I need some help properly setting up this
> document for 8.5" x 11" US Letter-sized paper. I don't understand  
> TeX enough
> to do this. I have made a few adjustments, but cannot find the  
> right one to
> get the payment data moved up more.
>
> Help?
>
> YOu may view the document here:
>
> http://pastebin.ca/1056580
>
> Thanks,
> -myk
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

[SL] need help with TeX

[Myk R. <myk...@gm...>]

Hey-

I am having trouble with my Vendor Invoice Template. The payments trail off 
the bottom edge of the page. I need some help properly setting up this 
document for 8.5" x 11" US Letter-sized paper. I don't understand TeX enough 
to do this. I have made a few adjustments, but cannot find the right one to 
get the payment data moved up more.

Help?

YOu may view the document here:

http://pastebin.ca/1056580

Thanks,
-myk

[SL] Pricegroup on Sales Order

[Sean E. <sea...@gm...>]

Has anyone gotten the pricegroup to show up on the Sales order screen or on
printed latex printouts?

If so, how did you do it?

Best regards,
Sean