17 Apr
2020
17 Apr
'20
10:35 a.m.
Hi Erik,
Thanks for your reply.
On Thu, Apr 16, 2020 at 08:08:56PM +0200, Erik Huelsmann wrote:
That's it! It certainly looked like a missing /g or equivalent but I had
no idea where to look for it. I've applied that fix now and all the
GRANTS succeed. Thank you.
However, there are still a tonne of SQL errors, some of which are no
doubt benign and a lot of which are just because the current transaction
has been aborted. I do see a few foreign key constraint violations which
look a bit concerning. The first such is this:
2020-04-17 11:06:52 BST ERROR: insert or update on table "menu_acl" violates
foreign key constraint "menu_acl_node_id_fkey"
2020-04-17 11:06:52 BST DETAIL: Key (node_id)=(134) is not present in table
"menu_node".
2020-04-17 11:06:52 BST STATEMENT: INSERT INTO menu_acl (node_id, acl_type, role_name)
values (134, 'allow', 'lsmb_testbooks__backup');
... which might be fine. There is indeed no 134 in menu_node - there's
nothing between 132 (Yearend) and 136 (Chart of Accounts) - but maybe I
just removed whatever that was years ago.
It is followed by the slightly more worrying-looking
2020-04-17 11:06:52 BST ERROR: insert or update on table "account_link"
violates foreign key constraint "account_link_description_fkey"
2020-04-17 11:06:52 BST DETAIL: Key (description)=(CT_tax) is not present in table
"account_link_description".
2020-04-17 11:06:52 BST CONTEXT: SQL statement "INSERT INTO account_link
(account_id, description) VALUES ( $1 , $2 )"
PL/pgSQL function "account_save" line 60 at SQL statement
2020-04-17 11:06:52 BST STATEMENT: SELECT account_save(id, accno, description, category,
gifi_accno, NULL, contra,
CASE WHEN link like '%tax%' THEN true ELSE false END,
string_to_array(link,':'))
FROM lsmb12.chart
WHERE charttype = 'A';
There is no CT_* of any sort in account_link_description. Is this something
necessary?
Thanks again,
Pete
--
Openstrike - improving business through open source
https://www.openstrike.co.uk/ or call 01722 770036
On Thu, Apr 16, 2020 at 2:48 PM Pete Houston
<ph1(a)openstrike.co.uk> wrote:
The upgrade to 1.3.x is just a stepping stone to reach a supported
version. I am going to have to go through a couple of iterations of
upgrading LSMB then upgrading postgresql to inch my way up the ladder.
If there's a better way, do please suggest it!
Hello,
I'm trying to upgrade an ancient LSMB (1.2.26) to a slightly less
ancient one (1.3.47) and the upgrade is not going smoothly, as you might
imagine.
Upgrading from 1.2 to something newer than 1.3 isn't available, I think,
but I'd like to urge you to pick something newer: 1.3 hasn't had any
maintenance for *years* -- if you'd pick something not too recent, like
1.6, at least you'd be able to fall back on the community support for help
and maintenance. With 1.3, no more fixes will be coming...
Is there anything we (the project) can help you with that would allow you
to pick a newer version? So, it looks
like the substitution of the second dbname token in that
line is not happening.
Can you suggest any reason why that might be and how/where I should go
about fixing it?
The problem stems from this line:
https://github.com/ledgersmb/LedgerSMB/blob/1.3/LedgerSMB/Database.pm#L674
There, the regex should have a 'g' at the end: s/.../.../g. With this
"g",
all occurrances in the string will be replaced instead of only the first
one.