We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 6726
    • 7,075 Posts
    After moving a MODx install several times, I had this error "Logging error : couldn’t save log to table !" (I am not the only one reporting this, Perrine did too)

    We found that the only way to stop having this warning which appeared every time we tried to access a manager page (after transfering a MODx site from a server to another), was to simply dump the modx_manager_log table and re-install from the install script (setup.sql).

    The problem is, now I get a new error when I try to add a snippet, a document or anything I have this error, "Couldn’t get last insert key!"

    Definitely, the "fix" to the "Logging error : couldn’t save log to table !" was dead wrong.

    The question is how do I solve this ?


      .: COO - Commerce Guys - Community Driven Innovation :.


      MODx est l'outil id
      • 22303 MODX Staff
      • 10,725 Posts
      Quote from: davidm at Apr 14, 2006, 07:46 AM

      The problem is, now I get a new error when I try to add a snippet, a document or anything I have this error, "Couldn’t get last insert key!"

      "Couldn’t get last insert key" error could occur if the table structures you migrated did not get AUTO_INCREMENT defined on the primary key. Is any data being persisted when that error appears?

      I suspect the logging error is being caused by the same issue. This almost always occurs when exporting using phpMyAdmin to generate MYSQL 3.23 compatible SQL files, and might also occur under other conditions.

        • 6726
        • 7,075 Posts
        I am not sure I understand the part about data being persisted, but as far as I am concerned, I used MySQL4 compatiblity, not 3.23. But thanks, at least I can try to fix this now, I’ll check the AUTO_INCREMENT for the primary keys...

        Edit : Checked, the id field of the manager_log table does have auto_increment.

        The only thing that is different when I compare the database from the test server and the one from the produciton server is the Cardinalility value of the PRIMARY key (which is quite normal since I re-created the manager_log tables...), value which I of course can’t change. Could this explain the problem ?

        If so, I’ll re-import the manager_log table, but then I would revert to my initial problem ( couldn’t save log to table).

        Another thing while I am here : the table can get pretty big in time (mine has 9804 entries !), is there a feature to delete records after a given time ? (yes there is)
          .: COO - Commerce Guys - Community Driven Innovation :.


          MODx est l'outil id
          • 6726
          • 7,075 Posts
          I am stuck with this problem, which causes other problems such as "$rs not set! New Chunk not saved!" when I try to add a new chunk... or "Internal Server Error" when I try to edit one...

          This is real BAD, the website is pratically unusable... it runs fine but I can’t change anything in fact.

          Any idea how to solve this ? (I mean the initial error before I tried to dump/recreate the modx_manager_log table and caused this wreck)
            .: COO - Commerce Guys - Community Driven Innovation :.


            MODx est l'outil id
            • 22303 MODX Staff
            • 10,725 Posts
            It still sounds like an indexes issue; either the the auto-increment indicators on the tables were not created, or something else which is preventing records from being inserted into the DB, such as corrupted tables, missing indexes. This is most likely a database-related or corrupted file on the filesystem issue though.
              • 6726
              • 7,075 Posts
              OK thanks I’ll check that, didn’t think of corrupted files...

              Basically, you’re saying dumping the modx_manager_log and recreating it couldn’t have caused this ?
                .: COO - Commerce Guys - Community Driven Innovation :.


                MODx est l'outil id
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: davidm at Apr 20, 2006, 11:11 AM

                OK thanks I’ll check that, didn’t think of corrupted files...

                Basically, you’re saying dumping the modx_manager_log and recreating it couldn’t have caused this ?

                Well, obviously, that could be part of the problem, but other tables or files related to one of the other tables (namely chunks in this case, or site_htmlsnippets) are suspect in this case as well.
                  • 6726
                  • 7,075 Posts
                  Okay... I did my homework and some deductive thinking, and finally found out that a difference between my MySQL local version and the one set up on my host was the cause of all this. It seems that those versions didn’t create SQL comments the same way...

                  The host setting is using # for comments,
                  The local setting is using -- for comments

                  When I imported the DB back via phpMyAdmin, I didn’t get syntax errors, the DB was created "normally" but I had those errors in MODx and all hell went loose...

                  I re-imported my backup fixing all the comments with the right prefix and bam : it works...
                  I honestly wonder what the h*ll is wrong with this host, they always have some funny config tweak that causes all sorts of problem... grrrr, lost quite some time on this. MODx was NOT involved...

                  Thanks Jason for pointing me in the right direction laugh !
                    .: COO - Commerce Guys - Community Driven Innovation :.


                    MODx est l'outil id
                    • 25468
                    • 18 Posts
                    OpenGeek,

                    You rock.. I was just starting to enjoy banging my head off the keyboard suring a migration to production.. change the id to ’auto increment’

                    Thanks..
                      /Gregg/