On Thu, 2007-04-26 at 19:04 -0700, Chris Travers wrote:
> Secondly, I would ask how you think our documentation compares to that
> of SQL-Ledger.
I have only skimmed the 1.1.12 manual, and it looks reasonably good. If
I read it thoroughly I would have specifics I guess. My suggestions were
for impr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Tangye wrote:
>
> My thought is to upgrade the SL database to 2.6.12, then migrate across.
>
> To upgrade in the SL database, download a sql-ledger 2.6.12 or later and
> just extract and run the 9 sql/Pg-upgrade... scripts from
> Pg-upgrade-2.4
Hi David;
Thank you for your reply. I appologize if I misunderstood you.
Here are the priority tiers as I see them:
1) Data and information assurance: Security, reliability, accounting
logic, and process control Without these, nothing else matters.
These are not possible without well structu
On Thu, 2007-04-26 at 18:12 -0700, Chris Travers wrote:
> The manual ought to be structured in such a way that a sole proprietor
> should be able to teach himself how to administer and use the software
> easily. The manual is designed to be worked through consecutively and
> that is why it is all
We are working on refactoring the codebase.
In 1.0.x and 1.1.x they are in the sql/ directory.
Because 1.2.x was to be the last upgrade with the current structure,
all the Pg-upgrade files were moved to sql/legacy/.
In 1.3.0 and higher, new upgrade scripts are likely to be somewhere
like sql/upg
On Thu, 2007-04-26 at 17:48 -0700, Chris Travers wrote:
> On 4/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-04-26 at 16:30 -0500, M Lubratt wrote:
> > > Except I manually executed the following from inside psql:
> > >
> > > # \i Pg-upgrade-2.6.12-2.6.17.sql
> > > # \i Pg-upgrade-
On 4/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-04-26 at 17:46 -0700, Chris Travers wrote:
> > First, I think that INSTALL and UPGRADE files should always be
> > maintained. Those filenames are in upper case not because I am
> > yelling but because that is the standard conventio
On Thu, 2007-04-26 at 17:46 -0700, Chris Travers wrote:
> First, I think that INSTALL and UPGRADE files should always be
> maintained. Those filenames are in upper case not because I am
> yelling but because that is the standard convention. If your install
> is a mess, I am guessing you didn't re
On 4/26/07, David Tangye <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-04-26 at 16:30 -0500, M Lubratt wrote:
> > Except I manually executed the following from inside psql:
> >
> > # \i Pg-upgrade-2.6.12-2.6.17.sql
> > # \i Pg-upgrade-2.6.17-2.6.18.sql
> Where did these files coma from. They is NO data
On Thu, 2007-04-26 at 13:59 -0700, Chris Travers wrote:
> Back up early, back up often :-) Back up in multiple ways :-) Not
> that this has anything to do with the data migration process itself.
> It is, however, always the safe thing to do.
I second that. Plus I am about to migrate using backups
First, I think that INSTALL and UPGRADE files should always be
maintained. Those filenames are in upper case not because I am
yelling but because that is the standard convention. If your install
is a mess, I am guessing you didn't read these files :-)
I do not expect we will ever stop maintainin
On Thu, 2007-04-26 at 16:30 -0500, M Lubratt wrote:
> Except I manually executed the following from inside psql:
>
> # \i Pg-upgrade-2.6.12-2.6.17.sql
> # \i Pg-upgrade-2.6.17-2.6.18.sql
Where did these files coma from. They is NO database upgrade at 2.6.17
and 18!! ... not even right thru to 2.6
On Thu, 2007-04-26 at 10:22 +0100, Ed W wrote:
> However, I don't disagree that in a perfect world we should have a
> better migration path. Perhaps someone will step up and help work on
> the migration scripts - these are never easy to write once a project has
> diverged far enough.
I am migr
Chris,
The schema version (if that's what you're interested in) was 2.6.12. I
ended up restoring my backup, then following the advice given by "The
Anacrat" (from another thread) outlined in:
http://wiki.koumbit.net/LedgerSmbTransfer
Except I manually executed the following from inside psql:
Back up early, back up often :-) Back up in multiple ways :-) Not
that this has anything to do with the data migration process itself.
It is, however, always the safe thing to do.
Best Wishes,
Chris Travers
On 4/26/07, Scott Martin <[EMAIL PROTECTED]> wrote:
>
>
> Chris Travers wrote:
> > Hi Sc
Chris Travers wrote:
> Hi Scott,
>
> I do not believe you can upgrade from SQL-Ledger to LedgerSMB just
> using the debians. We can help you to migrate your data, but the
> proper way would be to uninstall the first and install the second.
>
> Then read the README.debian if using a .deb or the
Hi Scott,
I do not believe you can upgrade from SQL-Ledger to LedgerSMB just
using the debians. We can help you to migrate your data, but the
proper way would be to uninstall the first and install the second.
Then read the README.debian if using a .deb or the UPGRADE file if
installing from a ta
Hello
I posted earlier about migrating from sql-ledger 2.4.7 to smb-ledger on
a debian sid box.
Would I be better off starting with a fresh install rather than trying
to recover my data.
I typically use this for writing quotes, issuing PO#'s, packing lists
etc. without using the full fledged acc
Take a look at something:
In psql:
select version from defaults;
Best wishes,
Chris Travers
On 4/26/07, M Lubratt <[EMAIL PROTECTED]> wrote:
> Well, I'm finally taking the plunge (on one installation at least).
>
> I've followed the Wiki instructions for migrating a SL installation to LS
> 1.1.
Well, I'm finally taking the plunge (on one installation at least).
I've followed the Wiki instructions for migrating a SL installation to LS
1.1.12. I've encountered a couple of issues and I'm wondering if someone
can point me in the right direction.
1. My cookies don't seem to be working (us
>
> It's not just a matter of creating reports, it's also of where they
> are stored and how it will trigger a status change for members within
> LS. So, if users fall behind in hours then they are switched to
> non-working members, and switched back on manually. I guess this can
> also be done as
Herb,
> It's not just a matter of creating reports, it's also of where they
> are stored and how it will trigger a status change for members within
> LS. So, if users fall behind in hours then they are switched to
> non-working members, and switched back on manually. I guess this can
> also be don
>
> > Much of this is standard LedgerSMB. The one feature which might be
> > some work is the tracking of member hours in conjunction with working
> > status. In our co-op members who work 2 hours a month are considered
> > working members and don't pay a surcharge. Members can bank these
> > hours
Hi
> (1) External access to accounting data - the will need serious
> controls, maybe even on a subnet.
Password protect the document, or leave the data-access link without a
wired in password (type it in each time)
> (2) Use of a potentially uncontrolled tool - you'll need to make sure
> you
Hi All,
I have been running 2.4.7 on Debian Sid for about a year now with no
luck updating thru the deb packages.
Would like to update to the latest and greatest smbledger.
I may have had some issues with the debs not allowing me to upgrade.
I am not a linux guru but can usually fumble my way a
Hmm, there's an idea..
Much of this is standard LedgerSMB. The one feature which might be
some work is the tracking of member hours in conjunction with working
status. In our co-op members who work 2 hours a month are considered
working members and don't pay a surcharge. Members can bank these
ho
> It depends on your benchmark, but do you think you might be seeing more
> of the open development which acknowledges bugs rather than real problems?
>
> I am just finishing up my end of year accounts with SL and I'm having to
> manually change the database in several places because SL keeps lo
> Much of this is standard LedgerSMB. The one feature which might be
> some work is the tracking of member hours in conjunction with working
> status. In our co-op members who work 2 hours a month are considered
> working members and don't pay a surcharge. Members can bank these
> hours and deplet
> That's probably what I would do one day when I feel SMB is more suitable
> to my business than SL.
Lets explore those reasons that are holding you back then? Are they
things which can be quickly sorted? There are several core developers
where who are prepared to reprioritise their developm
> I have held off migration from SL, because this trend of broken releases
> is concerning me, and I am seeing no evidence of any attempt to control
> releases properly. In fact I am seeing too much hackering here. This is
> not the way to convince many people to jump into the software, because
>
30 matches
Mail list logo
