Announcement

Collapse
No announcement yet.

Error After Order Numbers Rolled Over

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Error After Order Numbers Rolled Over

    I have a client who has a problem with the database odbc connection to the database that seems to be caused by the datbase itself. They are running v10.0.3LAFA.

    The error is:
    Actinic failed to open the database DSN=ActinicOriginal10. This prevents Actinic working.
    The error was:

    Data source name not found and no default driver specified


    To cut a very long story short I have installed Actinic on a new machine and it opens and appears to operate correctly with the sample database. Once I swop over to the live database however I get the error on either machine. The error only occurs when the stock synch is trying to do it's synch and uploading which happens just after downloading the orders. The orders download fine and catalog site updates are ok.

    The only thing that I can see to have caused it is that the orders numbers rolled over from 99999 to 00001. Immediatelly after that the error started - it never happened before.

    Has anyone experienced this before and know how to fix it?

    #2
    That would indicate a corrupt database - Actinic is failing to access it, rather than anything else - it could be that the change caused the database to corrupt though. Have you tried switching off stock synch and manually resetting the order number?

    Regards,
    Jan Strassen, Mole End Software - Plugins and Reports for Actinic V4 to V11, Sellerdeck V11 to V2018, Sellerdeck Cloud
    Visit our facebook page for the latest news and special offers from Mole End

    Top Quality Integrated label paper for Actinic and Sellerdeck
    A4 Paper with one or two peel off labels, free reports available for our customers
    Product Mash for Sellerdeck
    Link to Google Shopping and other channels, increase sales traffic, prices from £29.95
    Multichannel order processing
    Process Actinic, Sellerdeck, Amazon, Ebay, Playtrade orders with a single program, low cost lite version now available from £19.95

    Comment


      #3
      No, but the order numbers have wrapped, so effectively reset I presume. I think maybe I'll need help form support for this one.

      Comment


        #4
        As Jan states the error generated is from the windows ODBC drivers.
        I'd go into "Administrator Tools | Data Sources (ODBC)" and under "User DNS" click configure for the Catalog10 entry.
        You'll then get presented with a Repair and Compact option. I'd try both and see if that resolves the database/DSN corruption.
        Fergus Weir - teclan ltd
        Ecommerce Digital Marketing

        SellerDeck Responsive Web Design

        SellerDeck Hosting
        SellerDeck Digital Marketing

        Comment


          #5
          Unfortunately I've already tried that. I have also transferred the database to another machine and the problem seems to follow the database. Stangely it seems to be related to the order numbers rolling over. I'm going to look into that - the client uses orders numbers with five digits and they rolled over from 99999 to 00001 which seems to have triggered the issue.

          Comment


            #6
            Morning Duncan

            If not already done so, best to send the database to support, for development to have a look as you have mentioned above.

            Regards
            Krithika Chandrasekar
            SellerDeck

            sigpic

            E-commerce software by SellerDeck

            Comment


              #7
              In this case the client's order number was shortened in Orderscript.pl.

              From:
              Code:
               $::s_sOrderNumber = $sInitials . $sPostCode . substr($$::g_pSetupBlob{CGI_ID}, -1) .substr("0000000" . $nCounter, -7);
              to:
              Code:
              $::s_sOrderNumber = substr("00000" . $nCounter, -5);
              So the order number returned by the routine went from 99999 to 00000 and started again counting at 00001 etc.

              I don't understand why this seems to have caused the ODBC driver to fail though. Any ideas?

              I'm going to try changing the order number characters to 6 instead of 5 and see if that may help. In other words change the line to read:
              Code:
              $::s_sOrderNumber = substr("000000" . $nCounter, -6);

              Comment


                #8
                I could well be a bug in the stock synchronisation side of things. Clearly it needs to keep track of which orders are / aren't included in the present count and it looks as if the shortening of the order number count might have thrown it.

                In the database, the orders are indexed by the order sequence number but I guess the online stock synch has no way of using that instead of the order number as the orders haven't been downloaded into the database yet.

                On the other hand. this might well be un-related to the shortening of the order number. i.e. It might happen even with the default number of order digits. I guess it all depends on what Actinic have done to handle to case where the number rolls over.

                It shouldn't be too hard for actinic to replicate.

                Mike
                -----------------------------------------

                First Tackle - Fly Fishing and Game Angling

                -----------------------------------------

                Comment


                  #9
                  That may be the case Mike.
                  I've raised a support ticket and will send the database for checking.

                  Comment

                  Working...
                  X