if you upgraded django and the issue begins, wouldn't that point to the version of django? one would think so. however , rolling back to the older version of cx_Oracle fixes the issue. conclusion would be: it seems to be an issue when django > 1.4 AND cx_Oracle > cx_Oracle 5.0.3!
https://code.djangoproject.com/ticket/20292 says *This problem does not occur with Django 1.4.x or cx_Oracle 5.0.3!* we have the problem also. we can't rollback to the old cx_Oracle b/c it was buggy for us and we are told to upgrade to django 1.6. has anyone got a solution? :) thanks On Wednesday, April 10, 2013 10:50:04 AM UTC-4, Carsten Fuchs wrote: > > Hi all, > > last night I updated our productive system from Django 1.4.4 to 1.5.1, > and we're now seeing error "ORA-01843: not a valid month" when saving > data. > > OS is 32-bit Ubuntu 10.04 (fully updated) > cx_Oracle-5.1.1 > > Oracle database is on a remote host, version 10g Enterprise Edition > Release 10.2.0.5.0 > > This is the model definition that we're seeing the problem with: > > > class Erfasst(models.Model): > id = models.AutoField(primary_key=True) > key = models.ForeignKey(Mitarbeiter, db_column='key', > to_field='key', on_delete=models.PROTECT) > > datum = models.DateField() > status = models.ForeignKey(Status, db_column='status', > on_delete=models.PROTECT) > > anfang = models.CharField(max_length=8, blank=True) > ende = models.CharField(max_length=8, blank=True) > pause = models.CharField(max_length=8, blank=True) > faktor = models.SmallIntegerField(choices=[(60, "1.0"), (90, > "1.5"), (120, "2.0")], default=60) > > bonus_url = models.DecimalField(max_digits=5, decimal_places=2, > null=True, blank=True, verbose_name=u'Bonus-Urlaub') > bemerkung = models.CharField(max_length=40, blank=True) > bereich = models.ForeignKey(Bereich, null=True, blank=True, > on_delete=models.PROTECT) > zustand = models.SmallIntegerField(db_column='flag') > > approved_by = models.ForeignKey(User, null=True, blank=True, > on_delete=models.PROTECT, related_name='approved_set') > approved_at = models.DateTimeField(null=True, blank=True) > > last_user = models.ForeignKey(User, null=True, blank=True, > on_delete=models.PROTECT) > last_modified = models.DateTimeField(auto_now=True, null=True) > > > And this is an example from `./manage.py shell` that reproduces the error: > > >>> from Lori.models import * > >>> st = Status.objects.get(id=1) > >>> ma = Mitarbeiter.objects.get(key="F200") > >>> e = Erfasst(key=ma, datum=date(2013, 12, 12), status=st, > bemerkung="TEST CF", zustand=1) > >>> e.save() > Traceback (most recent call last): > File "<console>", line 1, in <module> > File > "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py", line > 546, in save > force_update=force_update, update_fields=update_fields) > File > "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py", line > 650, in save_base > result = manager._insert([self], fields=fields, > return_id=update_pk, using=using, raw=raw) > File > "/usr/local/lib/python2.6/dist-packages/django/db/models/manager.py", > line 215, in _insert > return insert_query(self.model, objs, fields, **kwargs) > File > "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line > 1661, in insert_query > return query.get_compiler(using=using).execute_sql(return_id) > File > "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", > line 937, in execute_sql > cursor.execute(sql, params) > File > "/usr/local/lib/python2.6/dist-packages/django/db/backends/oracle/base.py", > > line 717, in execute > six.reraise(utils.DatabaseError, > utils.DatabaseError(*tuple(e.args)), sys.exc_info()[2]) > File > "/usr/local/lib/python2.6/dist-packages/django/db/backends/oracle/base.py", > > line 710, in execute > return self.cursor.execute(query, self._param_generator(params)) > DatabaseError: ORA-01843: not a valid month > > > I also attach a full debug output page with additional details from our > live site, showing the same error. > > Some observed paradoxes: > > - I didn't receive any of the usual error e-mails that normally are > reliably sent whenever an application error like this occurs. The > attached page was generated by temporarily setting `Debug = True`. > > - On a second production system, which is also Ubuntu 10.04, but > 64-bit x86_64 with cx_Oracle-5.0.4 (and the exact same Django version > 1.5.1 and exact same application code, connecting to the same database), > this problem cannot be reproduced. Both in the shell as well as in the > application, everything works normally. The same is true for my > development system, which has a local database instance and > cx_Oracle-5.0.3, working normally. > > > It seems that the same problem has been reported at > http://stackoverflow.com/questions/15525312/django-oracle-backend-error, > but unfortunately I'm not able to derive any progress or solution from it. > > > What can we do? > > I consider downgrading to Django 1.4.5 on the affected system, as I'm > unfortunately unsure how to best proceed with debugging and/or fixing > this. > > Any help would very much be appreciated! > > Thank you very much, and best regards, > Carsten > > > > -- > Dipl.-Inf. Carsten Fuchs > > Carsten Fuchs Software > Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany > Internet: http://www.cafu.de | E-Mail: [email protected] <javascript:> > > Cafu - the open-source game and graphics engine for multiplayer 3D action > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a6b3de94-fca4-436f-9b9e-527f57723b76%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
