Hi Yves,
On Mon, Mar 21, 2016 at 4:15 AM, Yves Lavoie, GaYLi <ylav...@yveslavoie.com>
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.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
