Re: Fwd: Initial changes for SQL Ledger 3.0.x to LedgerSMB 1.4 migration

Hi Yves,

On Mon, Mar 21, 2016 at 4:15 AM, Yves Lavoie, GaYLi <..hidden..> wrote:

Hi Erik,

Here's what I got in Apache2 log files when the VM came back:

DBD::Pg::st execute failed: ERROR:  function public.setting_get(unknown) does not exist

LINE 1: SELECT * FROM "public"."setting_get"('ignore_version')

HINT:  No function matches the given name and argument types. You might need to add explicit type casts. at LedgerSMB.pm line 577.

Ok. This is expected: the file LedgerSMB/Database.pm assumes the database is a LedgerSMB database and then - if there's an error - tries the other recognised possibilitiies

2016/03/20 22:30:01 - ERROR - LedgerSMB::dberror LedgerSMB.pm (761) -- Logging SQL State 42883, error 7, string ERROR:  function public.setting_get(unknown) does not exist

LINE 1: SELECT * FROM "public"."setting_get"('ignore_version')

HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

This is the same error.

2016/03/20 22:30:01 - ERROR - LedgerSMB::_error LedgerSMB.pm (639) -- Internal Database Error

More information has been reported in the error logs at LedgerSMB.pm line 764.

2016/03/20 22:30:01 - ERROR - LedgerSMB::_error LedgerSMB.pm (640) -- dbversion: 1.4.27-dev, company: postgres

2016/03/20 22:30:01 - ERROR - LedgerSMB::_error LedgerSMB.pm (639) -- exit at LedgerSMB.pm line 653.

2016/03/20 22:30:01 - ERROR - LedgerSMB::_error LedgerSMB.pm (640) -- dbversion: 1.4.27-dev, company: postgres

exit at LedgerSMB.pm line 653.

Compilation failed in require at /home/ylavoie/src/LedgerSMB/git/LedgerSMB/login.pl line 8.

Ok. For login.pl, that's expected: it'll simply report that the database isn't an expected database type/version. In your case, the database is still the database from SQL Ledger, so, login.pl can't do anything with it.

[Sun Mar 20 22:30:01.419348 2016] [deflate:debug] [pid 2373:tid 3017780032] mod_deflate.c(855): [client 192.168.30.9:5047] AH01384: Zlib: Compressed 578 to 266 : URL /ledgersmb/login.pl, referer: http://ubuntu-vm/ledgersmb/setup.pl

[Sun Mar 20 22:30:01.482613 2016] [authz_core:debug] [pid 2372:tid 3051350848] mod_authz_core.c(809): [client 192.168.30.9:5048] AH01626: authorization result of Require ip 192.168.30.0/24: granted, referer: http://ubuntu-vm/ledgersmb/setup.pl

[Sun Mar 20 22:30:01.482657 2016] [authz_core:debug] [pid 2372:tid 3051350848] mod_authz_core.c(809): [client 192.168.30.9:5048] AH01626: authorization result of <RequireAny>: granted, referer: http://ubuntu-vm/ledgersmb/setup.pl

DBD::Pg::st execute failed: ERROR:  column "value" does not exist

LINE 1: SELECT value FROM defaults WHERE setting_key = $1

               ^ at LedgerSMB/Database.pm line 406.

DBD::Pg::st fetchrow_hashref failed: no statement executing at LedgerSMB/Database.pm line 407.

Assuming this is from an attempt to log in through setup.pl, this is expected too: The same strategy which causes the 'setting_get' error is used to access the database through setup.pl: if the table 'defaults' exists, then, if it has the correct columns, the database will be a LedgerSMB database.

DBD::Pg::st execute failed: ERROR:  permission denied for relation defaults at LedgerSMB/Database.pm line 428.

Now, this is unexpected: Are you logging in with a database superuser? If so, how can it be that the superuser can't access the 'defaults' table??

DBD::Pg::st fetchrow_hashref failed: no statement executing at LedgerSMB/Database.pm line 429.
[Sun Mar 20 22:30:03.994486 2016] [deflate:debug] [pid 2372:tid 3051350848] mod_deflate.c(855): [client 192.168.30.9:5048] AH01384: Zlib: Compressed 2394 to 884 : URL /ledgersmb/setup.pl, referer: http://ubuntu-vm/ledgersmb/setup.pl
This was after logging through setup.pl
Obviously, LedgerSMB has some dependencies on functions carried over from previous versions or on a new database.

Although I completely agree that it looks like it, I hope the above explains this isn't really the case. In 1.5, I've changed our code *and* our error reporting to suppress "expected" errors -- which aren't really errors, then. Unfortunately, in 1.4 it's too hard to see what are real errors and what aren't.

You're on the right track though. The thing that we're missing now is which user you're using and why that user doesn't have sufficient permissions.

I tried running settings.sql by hand or through reload_modules.sh but they fail on missing column in defaults.

Yea. Because the errors above are expected, this action shouldn't be required and to be honest, I don't expect it to succeed.

I'm available on #ledgersmb for most of the afternoon/evening again, so I hope to catch you there too.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.