Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-566

poll-billing.php and or schema mismatch issue

Details

    • Bug
    • Resolution: Fixed
    • Major
    • None
    • None
    • Billing
    • 4727. Upgraded to SVN from Open version.

    Description

      Timestamps are not getting entered for bill in/out port data. DB schema has field type as timestamp but INT is attempted to be entered. Timestamp is a not null and defaulted to current timestamp so simply commenting out the timestamp part of the SQL statement in PHP on poll-billing.php seems to fix the issue for me.

      Here is my code with commented out timestamp and attached image of my timestamps now getting udpated.
      dbInsert(
      array(
      'port_id' => $port['port_id'],
      //'timestamp' => $now,
      'counter' => $data['in'],
      'delta' => $in_delta
      ),
      'bill_port_in_data'
      );
      dbInsert(array(
      'port_id' => $port['port_id'],
      //'timestamp' => $now,
      'counter' => $data['out'],
      'delta' => $out_delta
      ),
      'bill_port_out_data');

      Attachments

        Activity

          [OBS-566] poll-billing.php and or schema mismatch issue

          tables dropped and updating code disabled.

          adama Adam Armstrong added a comment - tables dropped and updating code disabled.

          Oh I see, that table isn't used anymore. I think I was planning to allow per-port graphs, but that never happened and I don't think there's much use for it.

          I should probably just stop updating that table...

          adama Adam Armstrong added a comment - Oh I see, that table isn't used anymore. I think I was planning to allow per-port graphs, but that never happened and I don't think there's much use for it. I should probably just stop updating that table...

          Oh no, I see this too, yet the poller still works. How odd.

          adama Adam Armstrong added a comment - Oh no, I see this too, yet the poller still works. How odd.

          This sounds like an issue with your specific version/build of MySQL. This table and that code hasn't really changed for 9 years.

          adama Adam Armstrong added a comment - This sounds like an issue with your specific version/build of MySQL. This table and that code hasn't really changed for 9 years.

          Could be a schema issue too. Perhaps in my workflow I was using to get upgraded or installed the schema marking the table as a timestamp rather than an INT is the issue.

          bmerrell Brian Merrell added a comment - Could be a schema issue too. Perhaps in my workflow I was using to get upgraded or installed the schema marking the table as a timestamp rather than an INT is the issue.

          People

            codekiller Dennis de Houx
            bmerrell Brian Merrell
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: