Kryptronic Software Support Forum

There is a setting in the CCP Global Settings section that controls how long to keep orders.  It is based on time, however, and not on number of orders.  If you need a 'Keep Forever' option, I have a mod somewhere on the forum (Mods & Hacks section, probably) that adds that option.

Also, if I add the keep forever mod will it bring back past orders, or are those lost forever?

Thank you for the mod. It works! And how might I apply this same feature to keeping Customer Accounts forever? I do not want to lose customer emails and info. Would like to store them forever as well...

Last edited by ellehazen (02-27-2008 17:43:19)

As to the Quickbooks export, I can't really say... there have been a lot of posts about it on the board and I know it can work to some limited extent.  But I don't use it, so I don't really know any details.

Sorry, can you be more specific?  When did you do the change?  When did the orders disappear?  This mod should only have affected the customer accounts, not the orders.  Did you download a current copy of settings.csv before making the change?  Are we talking about orders or customer accounts now?

Could you please download a current copy of settings.csv and post the line that looks like this:

time_period_hold_tracking,PROGRAM,Time Period To Store Orders,0,SELECT-CUSTOM,Three Months:91|Six Months:183|One Year:365|Two Years:730|Five Years:1825|Keep Forever:0,Y

I have a hunch there is a typo or some sort of mistake in that line.  If not there, the problem must be in cron.pl.  You might want to also post the portion of the code that looks about like this:

#########
######### Get the tracking numbers for rows that we're going
######### to delete from the tracking table.
#########

if($time_period_hold_tracking > 0) {

$date_diff = "$time_period_hold_tracking";
$date_diff = ($date_diff * 60 * 60 * 24);
$date_diff = ($epoch_seconds - $date_diff);

$sql_statement = "

SELECT tracking_id
FROM tracking
WHERE tracking_epoch<'$date_diff'

";

my @tracking = database_call('tracking','SELECT',$sql_statement);

##########
########## Loop through the returned rows and delete the
########## associated rows from the trackitem table.
##########

foreach $row(@tracking) {

($tracking_id) = @$row;

$trackitem_delete_string .= "trackitem_tracknum='$tracking_id' OR ";

} ######### End of foreach statement.

@tracking = ();

if ($trackitem_delete_string ne "") {

chop($trackitem_delete_string);
chop($trackitem_delete_string);
chop($trackitem_delete_string);
chop($trackitem_delete_string);

$sql_statement = "

DELETE FROM trackitem
WHERE $trackitem_delete_string

";

&database_call('trackitem','DELETE',$sql_statement);

} ######### End of if statement.

#########
######### Now, delete all of the rows from the tracking
######### table that were identified as old.
#########

$sql_statement = "

DELETE FROM tracking
WHERE tracking_epoch<'$date_diff'

";

&database_call('tracking','DELETE',$sql_statement);

} #### End of if statement

Hopefully with that information, I'll be able to help you diagnose the problem.

Well, it looks right from here.  According to what you've posted, it should be keeping orders for one year.  Did the system time on your server change unexpectedly?

From what you've posted, it should be keeping orders for one year (the '360' in the line from settings.csv).  The only thing I can see that would make it otherwise would be if someone changed the time on your server (advanced it a year) so that the order seemed to be a year old.

If you post the URL, I can go place an order for you to see if its working.  Not sure why a minor change to the time period to store orders would keep anything from working on your site... unless perhaps settings.csv was uploaded in the wrong transfer mode (ascii instead of binary).  But you'd probably know it if something like that had happened... you'd see nothing but 500 errors on the site.