I released 1.3.43rc3. Please test it. It seems to work for me on some
limited test cases (on an existing db) but I would really like more
feedback. After that I will add test cases for travis-ci that test the
loadability of all the sql files.
On Mon, Sep 15, 2014 at 7:07 PM, Chris Travers <[email protected]>
wrote:
> I made some additional fixes to this file (well beyond this release). I
> will put out an rc-3 today
>
>
> On Mon, Sep 15, 2014 at 4:23 PM, Chris Travers <[email protected]>
> wrote:
>
>> I think I need to add some tests to Travis-CI that use
>> PGObject::Util::DBAdmin to test the loadability of these files.
>>
>> We have much better testing here on master and 1.4 than we do on 1.3....
>>
>> On Mon, Sep 15, 2014 at 10:47 AM, Michael Richardson <[email protected]>
>> wrote:
>>
>>>
>>> I tried 1.3.43rc2. I got past the employee__save, although I had
>>> two ghost postgres accounts half-created that I should have cleaned up
>>> first.
>>> I'll try again after dropping all the roles, but see the bottom of this
>>> email.
>>>
>>> I then got, in the edit function of the main system, trying to clean
>>> stuff
>>> up, no function employee__get, so I decided to do:
>>>
>>> ostgres@money13:/usr/share/ledgersmb$ psql credilorg
>>> psql (9.1.13)
>>> Type "help" for help.
>>>
>>> credilorg=# \i sql/modules/Employee.sql
>>>
>>> and I got:
>>>
>>> psql:sql/modules/Employee.sql:126: ERROR: syntax error at or near "."
>>> LINE 7: ee.startdate, ee.enddate, ee.role, ee.ssn, ee.sale...
>>> ^
>>> psql:sql/modules/Employee.sql:130: ERROR: function
>>> employee__get(integer)
>>> does not exist
>>> psql:sql/modules/Employee.sql:155: ERROR: return type mismatch in
>>> function
>>> declared to return employee_result
>>> DETAIL: Final statement returns date instead of boolean at column 7.
>>>
>>> looking deeper, I found the missing trailing ,
>>>
>>> mcr@money13:/usr/share/ledgersmb$ git diff !$
>>> git diff sql/modules/Employee.sql
>>> diff --git a/sql/modules/Employee.sql b/sql/modules/Employee.sql
>>> index ff6b454..8db9dd2 100644
>>> --- a/sql/modules/Employee.sql
>>> +++ b/sql/modules/Employee.sql
>>> @@ -114,7 +114,7 @@ CREATE OR REPLACE FUNCTION employee__get
>>> returns employee_result as
>>> $$
>>> SELECT p.entity_id, p.id, s.salutation,
>>> - p.first_name, p.middle_name, p.last_name, ee.is_manager
>>> + p.first_name, p.middle_name, p.last_name, ee.is_manager,
>>> ee.startdate, ee.enddate, ee.role, ee.ssn, ee.sales,
>>> ee.manager_id,
>>> mp.first_name, mp.last_name, ee.employeenumber, ee.dob,
>>> e.country_id
>>> FROM person p
>>>
>>>
>>> {I wonder if I should just upgrade from 1.2 to 1.4. An upgrade that
>>> skips a
>>> version is usually a bad idea, but maybe it's better tested... I suspect
>>> that
>>> many might still be at 1.2 due to fears about 1.3 stability...}
>>>
>>> It's also very hard to see the errors due to the verbosity, or even know
>>> where the errors are going during the upgrade process. Best I have done
>>> is:
>>> postgres@money13:/tmp/ledgersmb$ tail -f * | grep ERROR
>>>
>>> ===== this is what I get from the AddUser page:
>>> Error!
>>>
>>> Conflict with Existing Data. Perhaps you already entered this?
>>> More information has been reported in the error logs
>>>
>>> I understand the whole import user part; if I say "Yes", then it won't
>>> create a new database user. But I'm rather unclear what other info
>>> I need to supply, and I think that if I've just dropped that database
>>> role,
>>> then I shouldn't hit import.
>>>
>>> And more information doesn't get reported.
>>> Aha, it's in error.log:
>>>
>>> ==> /var/log/apache2/error.log <==
>>> DETAIL: Key (username)=(mcr) already exists.
>>> CONTEXT: SQL statement "insert into users (id, username, entity_id)
>>> VALUES (
>>> v_user_id,
>>> in_username,
>>> in_entity_id
>>> )"
>>> PL/pgSQL function "admin__save_user" line 49 at SQL statement
>>>
>>> After futzing around with creating a second user, I tried to edit the
>>> original "mcr" user and got:
>>>
>>> Error!
>>>
>>> 22P02:ERROR: invalid input syntax for type boolean: "manager"
>>> LINE 1: ...12-30', NULL, NULL, 'user', NULL, '1', NULL, '2', 'manager') ^
>>>
>>> from: ... well, doesn't help, it the URL hasn't changed.
>>>
>>> --
>>> ] Never tell me the odds! | ipv6 mesh
>>> networks [
>>> ] Michael Richardson, Sandelman Software Works | network
>>> architect [
>>> ] [email protected] http://www.sandelman.ca/ | ruby on
>>> rails [
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want excitement?
>>> Manually upgrade your production database.
>>> When you want reliability, choose Perforce
>>> Perforce version control. Predictably reliable.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Ledger-smb-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>>>
>>
>>
>>
>> --
>> Best Wishes,
>> Chris Travers
>>
>> Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
>> lock-in.
>> http://www.efficito.com/learn_more
>>
>
>
>
> --
> Best Wishes,
> Chris Travers
>
> Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
> lock-in.
> http://www.efficito.com/learn_more
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
