Error After Order Numbers Rolled Over

[Duncan Rounding]

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?

[Jan]

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,

[Duncan Rounding]

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

[fergusw]

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.

[Duncan Rounding]

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.

[Krithika]

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

[Duncan Rounding]

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

From:

 $::s_sOrderNumber = $sInitials . $sPostCode . substr($$::g_pSetupBlob{CGI_ID}, -1) .substr("0000000" . $nCounter, -7);

to:

$::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:

$::s_sOrderNumber = substr("000000" . $nCounter, -6);

[Mike Hughes]

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

[Duncan Rounding]

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