[web2py] Re: Strange behaviour on SQLFORM update

2010-12-15 Thread Seamon
Changing the id to e_id solved the problem pretty well and it's a nicer solution than type checking the id if it is a list. :) The funny thing is that this code actually worked on an older web2py server and the problem started after the update. Thanks for help. On 14. Dec., 17:11 h., DenesL wrote

[web2py] Re: Strange behaviour on SQLFORM update

2010-12-15 Thread DenesL
Massimo's suggestion seems to work for other integer fields but not for id. On Dec 15, 10:57 am, Seamon wrote: > Changing the id to e_id solved the problem pretty well and it's a > nicer > solution than type checking the id if it is a list. :) The funny thing > is > that this code actually work

[web2py] Re: Strange behaviour on SQLFORM update

2010-12-15 Thread DenesL
Neither works, same problem. On Dec 14, 10:19 pm, mdipierro wrote: > Try replace > > form.accepts (request.vars,session) > > with > > form.accepts (request.post_vars,session) > > or simply > > form.accepts (request,session)

[web2py] Re: Strange behaviour on SQLFORM update

2010-12-14 Thread mdipierro
Try replace form.accepts (request.vars,session) with form.accepts (request.post_vars,session) or simply form.accepts (request,session) On Dec 14, 10:11 am, DenesL wrote: > The problem is the use of 'id' in the vars. > What happens is that the form already has an 'id' field, although it > is

[web2py] Re: Strange behaviour on SQLFORM update

2010-12-14 Thread DenesL
The problem is the use of 'id' in the vars. What happens is that the form already has an 'id' field, although it is hidden it is still being sent back on submit, and then you add another 'id' in the vars so you end up with two, hence '|1|1|'. To fix just use a variable name that is not in the for