What's happening here is that DbRows can become None in this line
DbRows =
db(db.company.company_number==Company_ID).select(db.company.company_name).first()
So when you do DbRows['company_name'] you can get that error.
Basically you need to check if DbRows is None and raise HTTP(404)
--
Re
Can you try passing DbRows to your view and see if that works?
return dict(form=form, DbRows=DbRows)
Or, throw a print statement in there before session.company_name =
DbRows['company_name'] to see if DbRows['company_name'] has a value before
sending to the view?
-Jim
On Thursday, December
Well I was thinking that, BUT: I'm ALMOST convinced there is a bug in the
latest web2py:
CODE
--
Snippet of controllers/default.py
session.company = request.vars['Company']
Here is something strange as well - working thru the web2py console,
everything works:
[web2py@su-postgres-ben-3 web2py]$ python ./web2py.py -S Mec -M
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2018
Version 2.17.2-stable+timestamp.2018.10.06.18.54.02
Database drivers availab
It looks like the second line of your view if reassigning something else to
session.company. I don't believe the HTML comment tags are not going to
prevent web2py from executing that statement.
-Jim
On Thursday, December 6, 2018 at 12:22:30 PM UTC-6, Ben Duncan wrote:
>
> Well I was thinking t
Do you user virtual fields? Are you doing migrations while the scheduler
tasks are running. This is strange because it is a very fundamental piece
of web2py code that has not changed in long time:
for (i,row) in enumerate(rows):
for (j,colname) in enumerate(colnames):
value = row
On Monday, December 16, 2013 2:46:00 AM UTC+2, Massimo Di Pierro wrote:
>
> Do you user virtual fields? Are you doing migrations while the scheduler
> tasks are running. This is strange because it is a very fundamental piece
> of web2py code that has not changed in long time:
>>
>>
>>
Massimo,
Issue resolved. The source of all trouble was that the Scheduler uses the
same db connection as the task it executes. Thus output updates (print
'!clear!%(progress)s' % progress) changes the connection status, randomly,
hence the strange exceptions.
Suggestion: explicitly mention this as a gotc
they should be separated and they are separated from what I see in the
code. the db connection of the scheduler is on the main thread while
the one used by the task is inside the spawned process (the executor()
function). I don't see connections shared between the two.
On Monday, Decemb
9 matches
Mail list logo
