Kryptronic Software Support Forum

A script problem wouldn't be intermittent - the code would either be right or not.  Likewise, my first hunch about the host having changed the PERL configuration also would not be intermittent, so the answer here is not immediately obvious.  Intermittent DB connection seems possible, although that isn't what the error message would seem to imply.  This is definitely a problem with the host though, so probably worth contacting them to see what they say.  If you aren't able able to get it cleared up, you might want to contact Stephen at cartmod.com for some paid support work.

You're welcome, Jon.  I'd say it's either time for an upgrade to 6.0 or possibly a move to a dedicated server.  Which tables won't switch back to CSV?  If it's the tracking or trackitem tables, the problem is probably that they have become too large for CSV mode.  In that case, you'd have to clear some old data before changing them back.  Alternatively, you could reset the maximum CSV rows by editing tables.csv.  It is also possible to trick CCP into thinking it's running in CSV mode so that you can reset the database connection by editing that table as well - just be careful not to lose your data in the process (back up first!).

It might be that the intermittent error is due to a timeout because of the large tables, if the host has the MySQL server set up with tight restrictions... just a thought.  As for the PERL modules, I don't know that you would have the access (or the source) to recompile them on a shared server.  If you want to 'get them out of the way', you could just rename them temporarily (change the extension to .bak or something like that).  That would force the server to check the other locations and use the native modules, if they exist in the path.  If it doesn't work, all you have to do is rename them back.  As for the tracking and trackitem tables, if the problem is indeed their size, dumping them should fix the problem.  That would also take care of the problem if it happened to be a bad entry; so as long as you are sure you don't need that data, dumping the tables wouldn't be a bad way to start.  If you do need the data, you could do an export through phpMyAdmin before dumping them so you could reload them later if need be.