Hi Victor,
On Sat, May 1, 2021 at 1:20 AM Victor Wren <vwren(a)ponyhome.com> wrote:
$ perl -MLog::Log4perl::Layout::PatternLayout -E
'say "ok"'
Says "ok" so it (apparently?) doesn't think that PatternLayout.pm is
actually missing.
Yes, that's what it means indeed. Did you run this with a PERL5LIB
environment variable set? If so, we should make sure the same setting is
available in the environment in which the Starman process runs.
I forgot to mention that I WAS able to create a new
"demo" business, so
that much is working, at least,
despite some creative launching (right now I'm manually launching
starman-ledgersmb until I get around to
writing a SYSV init script for LFS) It's a shame mod_perl didn't come out
for 2.4 sooner, but what can you do. Still,
good to dust off the cobwebs from my server building skills.
Since you were able to create a new business, this means you're set up
pretty well and that the problem you're experiencing is likely "just"
related to your data.
BTW, there's a CentOS/RH-based SysV init script here:
https://github.com/ledgersmb/LedgerSMB/tree/master/doc/conf/sysvinit
hopefully that helps to (quickly) build one for LFS. I'd be happy to
include such an script in our repository for use by others or even just for
reference.
What it proposes is that you check the data in the
acc_trans table for
NULL values in the 'amount' column. A way to get rid of it (if it's not
referenced from anywhere) would be to run the query "DELETE FROM acc_trans
WHERE amount IS NULL". By "not being referenced from anywhere", I mean
that
the rows in acc_trans can themselves reference "invoice" rows or be
referenced by "payment_link" rows or "cr_report_line" rows (off the
top of
my head) and probably others. When those lines refer to these rows, either
the referencing rows are meaningless (likely this is the case for "invoice"
rows). Or they need to be replaced by a functional equivalent (this is
likely the case for "cr_report_line" rows). Links are supposed to be on the
"entry_id" field in the "acc_trans" table.
Doing "SELECT FROM acc_trans WHERE amount IS NULL" returns zero rows (on
both databases).
The "entry_id" column of table "acc_trans" is just sequential
numbers, as
far as I can tell. Maybe I misunderstand.
That's interesting. If there are no rows where "amount" is null in
acc_trans, then why does this query fail:
select trans_id, chart_id, transdate from acc_trans WHERE amount IS NULL
?
"payment_links" and "cr_report_line" are both empty tables in that
database.
Good. That simplifies the repairs we're looking at!
> Hope the above helps a bit!
> It gives me something to test, at least. I
was concerned that the
> database I was trying to convert might be too old (it's from a defunct
> business, but I'm 99% certain I've pulled it up in 1.3.x),
so I tried one that I used most recently before
upgrading, and got exactly
> the same result.
Any database that was dumped from LedgerSMB 1.2, is supposed to be
supported for the upgrade process. Due to lack of real life data, however,
this goal is hard to achieve. Regularly, databases show up with migration
issues (we're less likely to hear from successful migrations,
unfortunately); by solving the migration issues that *are* reported to us,
I hope to end up with a migration process that allows most people to
migrate their databases without problems.
BTW, migration from some versions of SQL Ledger are also supported, but
there's even less data available to us to test the correctness of those,
making it much harder to make any guarantees about correctness.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.