View Issue Details

IDProjectCategoryView StatusLast Update
0001809OXID eShop (all versions)1.03. Basket, checkout processpublic2012-12-10 13:23
Status resolvedResolutionfixed 
Product Version4.3.1 revision 27257 
Target VersionFixed in Version4.6.0_beta1 
Summary0001809: Faulty date and timestamp values within oxorderarticles entries
Description1) Order processing: INSERTs of oxorderarticle use the copied values of the assigned oxarticle object.
2) Order updating (e.g. within admin order_article class): Updating oxorderarticle requires to skip oxtimestamo field, which will be updated by database (on update CURRENT_TIMESTAMP).

Simply like it's done within oxarticle the following would fix it for oxorderarticle:

protected function _insert()
        // set oxinsert
        $iInsertTime = time();
        $now = date('Y-m-d H:i:s', $iInsertTime);
        $this->oxorderarticles__oxinsert = new oxField( $now );
        $this->oxorderarticles__oxtimestamp = new oxField( $now );

        return parent::_insert();

    protected function _skipSaveFields()

        $this->_aSkipSaveFields = array();
        $this->_aSkipSaveFields[] = 'oxtimestamp';
        $this->_aSkipSaveFields[] = 'oxinsert';

    protected function _update()


        return parent::_update();
PHP Versionany
Database Versionany



2010-05-05 15:29

reporter   ~0002625

Reminder sent to: thomas_oppelt


sorry, but i did not fully understand the problem you described. at the moment, it works this way:
when order is done in frontend, all product information (including OXINSERT and OXTIMESTAMP fields) is coppied into oxorderarticles db table.
if this order is updated via admin interface (changed amount of ordered product), OXINSERT and OXTIMESTAMP fields are not changed and stay the same. if new product is added to order via admin interface, OXINSERT and OXTIMESTAMP fields are coppied from oxarticle table for that product.

Are OXINSERT and OXTIMESTAMP fields changed in your case during order update via admin?

best regards,


2010-05-05 17:36

reporter   ~0002626

1) In a way you are right, my analysis did not match what actually happens, what appears seem to be a date (re)formatting issue, try this to reproduce:
Ordering within GERMAN language, then you get a "d.m.Y" formatted date within insert statement of oxorderarticle, which has to fail (e.g. 23.10.2009 becomes 2023-10-20 .. some databases of german shops we checked for that are full with nonsense dates which lie ahead like this.)
2) oxorderarticle.OXTIMESTAMP has an "on update CURRENT_TIMESTAMP" attribute so of course it is intended to be updated by database itself, or not?


2011-12-14 10:12

manager   ~0005489

added 'oxtimestamp' to _aSkipSaveFields array and fixed, that 'oxorderarticeles.oxinsert' is the same as 'oxarticeles.oxinsert'.