Karen,
That was a good idea, trying from the manage.py shell:- it worked
perfectly...
So then I changed the form and just hard-coded the return value, like:
#up.telephone=self.cleaned_data['telephone'],
up.telephone="370 5814"
up.save()
(This closely duplicated what I had just tried in the shell, and of
course, it worked perfectly!)
Where this is in the form's save() function, called after a successful
validation of all the fields, and up is the object instance of the
Userprofile class mentioned several posts above.
Seems like the cleaned_data functionality isn't working quite like I
expected. And now, typing this, I just noticed, why is there a comma
at the end of the commented-out statement? Oh dear, oh dear, oh dear!
A whole DAY down the tubes because of a stupid comma!!! Arrgggh!
Sometimes it's all to easy to think that the cause of a problem is
something far more complex and esoteric than it really is! So thanks
Karen, for suggesting the manage.py shell - if I hadn't tried that I
would have remained convinced that it was *django* or *mysql* getting
it wrong, when all along it was ME!
So thanks again Karen, and Scott, for helping an idiot! :) At least
now, I'm a *happy* idiot!
On Jul 1, 1:57 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2008 at 7:36 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 30, 2008 at 7:19 PM, Simon Tite <[EMAIL PROTECTED]> wrote:
>
> >> > However, it could be that the problem is lurking at the beginning of
> >> > the SQL statement, which I haven't been able to see yet....
> >> > ...so, how does one go about looking at the actual SQL which is passed
> >> > to the database engine? Is this possible? I suppose it must be, if I
> >> > spent several hours diving into the Django source, but hopefully
> >> > somebody knows an easier way? Somebody? Anybody?
>
> > If you can recreate the problem from a python manage.py shell session,
> > then:
>
> > from django.db import connection
> > connection.queries[-1]
>
> > will show the last query sent to the database (modulo some quoting).
>
> > If you cannot recreate it from a shell session you can always turn on query
> > logging on the mysql side (assuming this is not a production database?).
> > Details on how to do that would depend on the platform you are running MySQL
> > on.
>
> > You haven't said much about where the data for this object is coming from
> > (other than "a form") I think? More details might help people pinpoint what
> > is wrong. However the error you are getting is strange. If it were strings
> > too long for the fields because of quotes you would have gotten a truncation
> > error, not the general "there's something wrong with your sql" syntax
> > error. There seems to be something fundamentally broken in your setup, but
> > I have no idea what it is at this point.
>
> Or even easier just recreate however you are generating it in the first
> place with debug=True in the settings.py file and the traceback debug page
> will probably have the sql statement findable somewhere among the local
> variables in the traceback.
>
> Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
