Great! Good to hear it's mostly working now. I'm sure Chris and I will find
the problem with the user-creation tomorrrow morning.
Bye,
Erik.
On Fri, May 17, 2013 at 10:42 PM, Chris Calef wrote:
> And... DING DING DING!
>
> "This database operation has completed successfully. LedgerSMB may now
And... DING DING DING!
"This database operation has completed successfully. LedgerSMB may now be
used."
Thanks very much for all the help, that did it!
Just in case any other part time SQL newbies follow along here, the precise
syntax on create user for my version of postgres is:
create user cc
On Fri, May 17, 2013 at 9:41 PM, Chris Calef wrote:
> Hm,
>
> "This can be worked around easily enough by logging in with psql (as
> postgres, any db), and CREATE USER '[username]' before creating the
> database. Then you can select 'yes' in the import option and this works
> properly. However it
I went back and tried saying Yes to Import, not sure how that is supposed
to work, but with a new database name it fails because database doesn't
exist, and with a new user on an existing database I get the same "can't
grant permissions to a non existent user" message.
On Fri, May 17, 2013 at 1
Hm,
"This can be worked around easily enough by logging in with psql (as
postgres, any db), and CREATE USER '[username]' before creating the
database. Then you can select 'yes' in the import option and this works
properly. However it does need to be fixed before next beta."
Does [username] refer
On Fri, May 17, 2013 at 9:19 PM, Chris Calef wrote:
> Hmm... well, we got rid of all the errors in dblog!
>
> There was one more error after your commit, the same issue but with
> "journal__save_recurring_print" instead of "journal__save_recurring"... I
> went ahead and did the same RETURN * thin
Also, just so you know, I'm still getting a database created, but no users
added, at the point where it crashes (which is just after filling in the
new user information and clicking okay).
On Fri, May 17, 2013 at 12:19 PM, Chris Calef wrote:
> Hmm... well, we got rid of all the errors in dblog!
Hmm... well, we got rid of all the errors in dblog!
There was one more error after your commit, the same issue but with
"journal__save_recurring_print" instead of "journal__save_recurring"... I
went ahead and did the same RETURN * thing after that and the error went
away.
However, my browser stil
Hi Chris,
Nobody was working on it, so I took the liberty to commit a fix. Could you
tell me if it works now?
Bye,
Erik.
On Fri, May 17, 2013 at 8:31 PM, Chris Calef wrote:
> Hi, not sure if people are still in the middle of working on this, but I
> saw there were updates so I tried it again
Hi, not sure if people are still in the middle of working on this, but I
saw there were updates so I tried it again. Results: not _quite_ there,
but only one error this time!
The offending statement is this:
psql:sql/modules/Transaction_Templates.sql:161: ERROR: return type
mismatch in functio
Just letting folks know:
With svn 5815 I was able to create a new fresh db. It took a bit longer
because the new Roles.sql format doesn't get processed as quickly as the
old format (however, it is now transactional and does a bunch of sanity
checks which make it better for working with addons, et
Just letting everyone know, I am working on the Roles.sql, entirely
rewriting it so that it runs repeatably and transactionally.
I expect to have it committed shortly.
Best Wishes,
Chris Travers
On Thu, May 16, 2013 at 11:46 PM, Erik Huelsmann wrote:
> Hi Chris,
>
> Still got quite a few er
Hi Chris,
Still got quite a few errors, although you fixed several with that
> round...
>
> There was one more report_id vs adjust_id problem in Inventory_Report.sql,
> line 53, fixed that myself but you'll want to do it in the repo:
>
> psql:sql/modules/Inventory_Report.sql:58: ERROR: column l.r
Hi again,
>Thanks for hanging in!
No problem, thanks for the help!
Still got quite a few errors, although you fixed several with that
round...
There was one more report_id vs adjust_id problem in Inventory_Report.sql,
line 53, fixed that myself but you'll want to do it in the repo:
psql:sql/mo
Hi Chris,
On May 16, 2013 12:53 AM, "Chris Calef" wrote:
>
> Thanks again, Erik! Unfortunately, still not quite there yet... but
we're getting closer!
Thanks for hanging in!
>
> Here are my current errors:
>
> psql:sql/modules/EndOfYear.sql:28: ERROR: function
eoy_reopen_books(date) does not
Thanks again, Erik! Unfortunately, still not quite there yet... but we're
getting closer!
Here are my current errors:
psql:sql/modules/EndOfYear.sql:28: ERROR: function eoy_reopen_books(date)
does not exist
LINE 6: SELECT eoy_reopen_books(end_date)
-
On Wed, May 15, 2013 at 11:58 PM, Chris Calef wrote:
> Ah, I get it now... all those errors are references to menu_node entries
> that don't exist.
>
Yea, that's it indeed.
Were you able to get the database to work with the fixed Roles.sql file?
Bye,
Erik.
--
Ah, I get it now... all those errors are references to menu_node entries
that don't exist. Pg-database.sql fills menu_node with the following
(clipped for brevity):
COPY menu_node (id, label, parent, "position") FROM stdin;
91Search Groups776
92Search Pricegroups778
6
Hi Chris,
On Wed, May 15, 2013 at 9:02 PM, Chris Calef wrote:
> Hi again,
>
> Sorry, got distracted away from keys for a day or two, but I just updated
> and tried my setup.pl again, and _almost_ all my errors went away with
> the recent changes to Reconciliation.sql. (Yay!)
>
> The main one th
Hi again,
Sorry, got distracted away from keys for a day or two, but I just updated
and tried my setup.pl again, and _almost_ all my errors went away with the
recent changes to Reconciliation.sql. (Yay!)
The main one that is still shows up repeatedly looks like this:
psql:/tmp/ledgersmb/lsmb_r
On Sun, May 12, 2013 at 12:02 AM, Chris Calef wrote:
> Hm, well I got a different set of errors this time anyway. Attached is
> another version of fullpermissions.error.log.
>
> The first error claims that my database does not exist, but it did get
> created. Again I got as far as the create us
Hm, well I got a different set of errors this time anyway. Attached is
another version of fullpermissions.error.log.
The first error claims that my database does not exist, but it did get
created. Again I got as far as the create user screen before crashing.
The database has all the tables, but
Hi Chris,
On Sat, May 11, 2013 at 2:29 AM, Chris Calef wrote:
> Thanks, Erik!
>
> Clearly my first problem was me trying to be too helpful, I didn't realize
> that setup.pl was going to create the database for me!
>
> That being resolved, though, I tried it with a new name, and it looked
> good
Thanks, Erik!
Clearly my first problem was me trying to be too helpful, I didn't realize
that setup.pl was going to create the database for me!
That being resolved, though, I tried it with a new name, and it looked good
through the first user page, where I filled in all the fields
appropriately.
Hi Chris,
Thanks for writing up your issues. I'm in the process of installing 1.4
(trunk) as well - also from svn.
On Fri, May 10, 2013 at 10:51 PM, Chris Calef wrote:
>
> In installing 1.4 from the svn, I ran into some confusion about the
> preferred (or any) method for creating the company da
Hi,
In installing 1.4 from the svn, I ran into some confusion about the
preferred (or any) method for creating the company database and populating
it with the initial default users.
I tried running setup.pl and pointing it at a blank database, but it
reported "unknown database". Next I ran Pg-da
26 matches
Mail list logo
