I have launched 4 new CS-Cart 3.0.4 Professional websites, on two seperate servers in the last two weeks and each site has the same issues with reporting memory problems.
I can’t even open the reports on one of my sites. I click on reports, wait a few minutes and i’m present with the following message
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 16 bytes) in /home/xxxxxx/public_html/xxxxxx/core/fn.common.php on line 542
Any ideas? Is there a fix?
I have several stores to purchase licenses for and migrate over, but i’m frankly worried about this.
I’m also having issues with the new import tool as well. Some sites it works and other not.
In Administration>Database>PHP Information, what is your servers 'memory_limit' set to? Are these values overriden by either htaccess rules or local php.ini, which will be in the public_html folder if it exists?
How much data are we talking? X Orders, X Customers, X Products?
Memory Limit is set to 256Mb
317 orders / 101 customers / 200 Products
Something isn't right there then. I can load the reports on sites with more than tenfold those stats without any problems. Must be a problem with either your install, your database or your hosting. Best to get CS-Cart to investigate this for you.
Definitely something going here. I started support ticket, hopefully we'll hear back soon.
Mikhail sent me a sql file to reset the report settings, and we have reports back now.
The memory issue only on seems to occur when we select a time period of a month or more regardless of how much data there is.
It may also be worth pointing out that it is happening on every site that we have running CS-Cart 3.0.4, regardless of server, or server configurations.
I just converted a site from Interspire to CS-Cart, with virtually all data migrated via Cart2Cart as well as manually exporting/importing data into the database.
Using 3.0.4 Ultimate, I checked the reports to see if the data matched what was shown in Interspire, which it was. Reports ran fine for all order data going back to the beginning of the site in 2006.
I get a 404 when I try to run Sales Reports.
There are no errors in CS-Cart logs and no errors in server logs. I don't know what is causing this, but Sales Reports have always had a problem near the end of the year when the annual data would be at the maximun. But the volume is really not that high.
OK here is what I has been found in the core/fn.sales_reports.php file.
This is for CS-Cart Pro v3.0.4 and you may find the same in earlier versions since I see this bug has been making the rounds.
In the file core/fn.sales_reports.php around line 72 (or do a search for $time_end += ($intervals['0']['interval_id'] == '7') ? (mktime(0, 0, 0, date("m", $time_end) + 1, 1, date("Y", $time_end)) - $time_end) : $temp['value'];
and replace the mktime with gmmktime et viola. Works as it should now.
I'm in GMT -05 time zone and support had to make an additional change to the same line just to get reports to run:
$time_end += ($intervals['0']['interval_id'] == '7') ? ([color=#B22222]gmmktime[/color](0, 0, 0, date(“m”, $time_end) + 1, [color=#B22222]3[/color], date(“Y”, $time_end)) - $time_end) :
Now the problem is with the starting and ending dates of reports, order searches, the customer's birthday and the sales amounts on the dashboard.
I've discovered that if I leave the line as:
$time_end += ($intervals['0']['interval_id'] == '7') ? ([color=#B22222]gmmktime[/color](0, 0, 0, date(“m”, $time_end) + 1, [color=#B22222]1[/color], date(“Y”, $time_end)) - $time_end) :
Then, when I change my Time Zone to GMT -01 thru GMT -09 (in Settings > Appearance) Today includes yesterday, for all time intervals selected.
It appears as though when selecting GMT +01 thru GMT +13, Today includes tomorrow for all time intervals.
Only if you select GMT (Greenwich Mean TIme) are all time intervals correct - even the Dashboard totals.
I opened a ticket on this issue and am waiting to see what changes.
I ended up changing back to “mktime” and it will now run reports when I have the (GMT -08:00) set to pacific standard time:
$time_end += ($intervals['0']['interval_id'] == '7') ? (mktime(0, 0, 0, date(“m”, $time_end) + 1, 1, date(“Y”, $time_end)) - $time_end) : $temp['value'];
I have a multisite client with this issue (out of memory).
Can anyone publish the actual SQL that was referenced in message #6?
I'm guessing there is a DB issue that is causing this to suck down the machine versus the time specification (should work with all times if the DB is correct).
UPDATE cscart_sales_reports SET period = 'D';
UPDATE cscart_sales_reports_table_elements SET limit_auto = '20';
All you are doing is resetting the report period to Daily.
I find that when I choose Last Year from the report's drop down, it will time out and I have to go in and reset the period so I can bring the report back up. I can run quarterly reports on last year that don't cause this to happen, so I just stopped using “Last Year”.
Also, CS-Cart undid the changes that implemented gmmktime. One of the last updates to v3 fixed a discrepancy where gmmktime was still being called. All the time/date values are using mktime. That fixed the bug with customer's birthdays too.
I hacked the following solution. This is entered just below the gmmktime line:
// EZms hack for infinate loop
if( $time_end == $temp['time_from'] )
$time_end += $temp['value'];
// EZms end hack
Since the memory issue seems to be an infinite loop where $time_to is always greater than $time_end when using the monthly report (the default and the trigger for the gmmktime function - interval_id == 7 for monthly report).
Don't have time to debug this properly. But then that should be cs-cart's job anyway.
You're not editing ver 3.0.5 or greater are you? gmmktime was replaced universally with mktime in v3.0.5. There was a bug where gmmktime was still being called in one or two places - even though mktime was already used in the rest of the code. It threw off all dates by -1 day (including reports, orders lists, dashboard totals, customers DOB).
These are 3.0.4 sites… All I know is that the “out of memory” was caused by an infinate loop. I can deal with the 1 day variance in months (other than Feb) and like I said, I don't have time to figure out the “right” solution for this.
I just started getting the Fatal error today but my [color=#282828][font=arial, verdana, tahoma, sans-serif]fn.sales_reports.php already has mk and not gmmk (version 2.0.9). Has anyone found a fix for this? I have scoured these forums all day today but have not found a concrete answer. Here is my error when I try to log in as admin:[/font][/color]
Fatal error[color=#000000]: Allowed memory size of 1048576000 bytes exhausted (tried to allocate 262117 bytes) in [/color]/home/x/public_html/core/fn.log.php[color=#000000] on line [/color]70
Can anyone help?