Could somebody help me work out what this means in 1.6?:
Statistics is currently in catchup mode. So far 1 day(s) have been processed and 10 are pending. Check back soon!
The thing is statistics are always in catchup mode on the site and I can't work out how to force it to catch up.
Darren
I can sympathize. I have yet to get statistics to catchup. There is virtually no feedback as to what it is doing and I have not gone in to look at the code. I have also found it difficult to get to fire back up again. It would be nice if there could be some more feedback. I liked the approach taken for utf migration. It used the configuration debug option to determine what level of detail to show, had a status bar and you could clearly go in to the database and see where it was. Something similar with statistics would be helpful. I am afraid that folks converting will be curious about this feature but (as I did) quickly abandon it because it does not seem to be working nor worth the trouble.
Perhaps you could try posting what your config variables are for stats? In particular:
statsfirstrun:
This specifies how far back the logs should be processed the first time the cronjob wants to process statistics. If you have a lot of traffic and are on shared hosting, it's probably not a good idea to go too far back, as it could take a long time to run and be quite resource intensive. (Note that for this setting, 1 month = 28 days. In the graphs and reports generated, 1 month = 1 calendar month.)
statsmaxruntime:
Stats processing can be quite intensive, so use a combination of this field and the next one to specify when it will run and how long for.
statsruntimestart:
What time should the cronjob that does the stats processing start?
statsfirstrun:
This specifies how far back the logs should be processed the first time the cronjob wants to process statistics. If you have a lot of traffic and are on shared hosting, it's probably not a good idea to go too far back, as it could take a long time to run and be quite resource intensive. (Note that for this setting, 1 month = 28 days. In the graphs and reports generated, 1 month = 1 calendar month.)
statsmaxruntime:
Stats processing can be quite intensive, so use a combination of this field and the next one to specify when it will run and how long for.
statsruntimestart:
What time should the cronjob that does the stats processing start?
Hello, thanks for the response.
I have been playing with the variables but they don't seem to make much difference. I am still one day complete with 12 pending now. Obviously the script must have ran at least once at the start but I'm still not convinced that it is doing anything now The traffic on my site isn't huge (~500 hits daily average).
Currently my settings are yes, all, until complete, 00:00 and 0 but I have tried other combinations.
I have been playing with the variables but they don't seem to make much difference. I am still one day complete with 12 pending now. Obviously the script must have ran at least once at the start but I'm still not convinced that it is doing anything now The traffic on my site isn't huge (~500 hits daily average).
Currently my settings are yes, all, until complete, 00:00 and 0 but I have tried other combinations.
Hi - can you do the following for me:
run this query:
select * from mdl_config where name like '%stats%';
(this will give a few more pieces of information)
and change the start time to 1am and see if that makes a difference.
run this query:
select * from mdl_config where name like '%stats%';
(this will give a few more pieces of information)
and change the start time to 1am and see if that makes a difference.
Hrmm, ok that attachment shows that there isn't anything wrong with your stats (I had thought maybe there was a stale lock).
Yes, wait til the 1am one goes and then see.
Also, look for the output of cron, it should stay stuff like
'starting daily statistics gathering...'
and then print some dates and tell you what it's doing and how many days it has done.
Yes, wait til the 1am one goes and then see.
Also, look for the output of cron, it should stay stuff like
'starting daily statistics gathering...'
and then print some dates and tell you what it's doing and how many days it has done.
Hello.
I changed the time to 00:30 and triggered it manually just after (a few times) and nothing about stats appeared in the list. Also tried at 35 and 40 and still no mention.
Interestingly I have a test site on a different server / network and I tried that (latest nightly also). Cron hadn't been run on it for many days and I got 'starting daily statistics gathering...' at the bottom the first time and that was it - nothing else (same variables as mentioned earlier). I changed the time on the test server and triggered cron manually at 00:30 and I got a stale lock error in the cron list! I changed the times again in line with the above tests on the test server and 'starting daily statistics gathering...' has not appeared on the list since and the number of days remained the same
I changed the time to 00:30 and triggered it manually just after (a few times) and nothing about stats appeared in the list. Also tried at 35 and 40 and still no mention.
Interestingly I have a test site on a different server / network and I tried that (latest nightly also). Cron hadn't been run on it for many days and I got 'starting daily statistics gathering...' at the bottom the first time and that was it - nothing else (same variables as mentioned earlier). I changed the time on the test server and triggered cron manually at 00:30 and I got a stale lock error in the cron list! I changed the times again in line with the above tests on the test server and 'starting daily statistics gathering...' has not appeared on the list since and the number of days remained the same
ok -- another question for me, can you do
select count(*) from mdl_stats_daily;
and
select count(distinct(timeend)) from mdl_stats_daily;
and if you have skype, it might be easier to discuss this over IM.
select count(*) from mdl_stats_daily;
and
select count(distinct(timeend)) from mdl_stats_daily;
and if you have skype, it might be easier to discuss this over IM.
Hi Penny, Darren,
The site I am using is not live, and no-one is using the database, but I have a lot of data from the 19th of April and before. I, too, am in catch up mode, have processed 0 days and have 14 days pending. When I initially ran the cron manually it kept giving me errors on modules - dialogue, exercise, hotpot and then book. I deleted all these one by one and reset the config variables. The last time I ran cron it just hung on Running daily statistics gathering... There is still nothing in any of my stats tables.
It is trying to look 2 weeks back (so there is a week worths of live data from 200 courses). I ran it two hours ago and the config fields look like this:
Any help appreciated.
Paolo
The site I am using is not live, and no-one is using the database, but I have a lot of data from the 19th of April and before. I, too, am in catch up mode, have processed 0 days and have 14 days pending. When I initially ran the cron manually it kept giving me errors on modules - dialogue, exercise, hotpot and then book. I deleted all these one by one and reset the config variables. The last time I ran cron it just hung on Running daily statistics gathering... There is still nothing in any of my stats tables.
It is trying to look 2 weeks back (so there is a week worths of live data from 200 courses). I ran it two hours ago and the config fields look like this:
Any help appreciated.
Paolo
you have enablestats set to 0. this means stats will not run.
Penny, aah... how embarassing - my mistake. However, that wasn't the case before and,even now, if I go Moodle stats it says "stats enabled 'yes'" (cache issue?)... Having said that, now I have resaved that page the image has reverted and my data looks like:
When I run the cron now I do have the stale lock on:
I still am catch up mode, have processed 0 days and have 14 days pending.
Any ideas/instructions?
When I run the cron now I do have the stale lock on:
I still am catch up mode, have processed 0 days and have 14 days pending.
Any ideas/instructions?
On running the cron again a few minutes later I get:
And the data looks like:
If I go to stats from the front page I get the same catch up mode statement with no data in any of my stats tables.
And the data looks like:
If I go to stats from the front page I get the same catch up mode statement with no data in any of my stats tables.
very strange...
php version? database type and version? anything in the database error log?
php version? database type and version? anything in the database error log?
PHP 5.0.4
MySQL 4.1.16
Moodle 1.6 Beta3
I've had a little look at this and as far as I can tell there seems to be two problems (+1):
From function stats_check_uptodate in /lib/statslib.php I understand we are going to throw up the message we are in catch up mode if:
1. it is not 2 days before the date we want to get statistics:
2. days pending is equal to zero and we havent processed any days:
(my days pending is 14 and my days done 0)
So basically if I enter that function I will throw that error. This seems wrong. * Presumably this should be greater than.
If I override those checks and return true from that function I get There is no available data to display, sorry. This, I think, is a different problem.
This is caused by earliestday, week, month using todays date as the stats tables are empty. This means that timeoptions is null because nothing is set in function stats_get_time_options as none of the below type statements are true.
If I enter a valid earliestday,month, year I get a page from which i can search statistics. I use this to search it tells me that stats.php does not exist, which is a third problem I think I saw this problem in the bug tracker.
Does all this make sense?
MySQL 4.1.16
Moodle 1.6 Beta3
I've had a little look at this and as far as I can tell there seems to be two problems (+1):
From function stats_check_uptodate in /lib/statslib.php I understand we are going to throw up the message we are in catch up mode if:
1. it is not 2 days before the date we want to get statistics:
if ((time() - 60*60*24*2) < $latestday) { // we're ok
return true;
}
*return true;
}
2. days pending is equal to zero and we havent processed any days:
if ($a->dayspending == 0 && $a->daysdone != 0) {
return true; // we've only just started...
}
return true; // we've only just started...
}
(my days pending is 14 and my days done 0)
So basically if I enter that function I will throw that error. This seems wrong. * Presumably this should be greater than.
If I override those checks and return true from that function I get There is no available data to display, sorry. This, I think, is a different problem.
This is caused by earliestday, week, month using todays date as the stats tables are empty. This means that timeoptions is null because nothing is set in function stats_get_time_options as none of the below type statements are true.
if ($now - (60*60*24*7) >= $earliestday) {
$timeoptions[STATS_TIME_LASTWEEK] = get_string('numweeks','moodle',1);
}
$timeoptions[STATS_TIME_LASTWEEK] = get_string('numweeks','moodle',1);
}
If I enter a valid earliestday,month, year I get a page from which i can search statistics. I use this to search it tells me that stats.php does not exist, which is a third problem I think I saw this problem in the bug tracker.
Does all this make sense?
I think the code in that function is corerct, but the problem is that you have no data in your stats table.
I don't know about stats.php being missing, I wrote stats a while ago and all the reporting related files were moved around afterwards. If you could point to the bug tracker # that would be helpful.
Are you running cron from command line php or from wget/curl? If you're using wget/curl can you check the apache error log?
Also, can you check the mysql error log? You may need to increase the error reporting level, I can't help there, I purged all mysql knowledge when I discovered postgres.
I don't know about stats.php being missing, I wrote stats a while ago and all the reporting related files were moved around afterwards. If you could point to the bug tracker # that would be helpful.
Are you running cron from command line php or from wget/curl? If you're using wget/curl can you check the apache error log?
Also, can you check the mysql error log? You may need to increase the error reporting level, I can't help there, I purged all mysql knowledge when I discovered postgres.
>If
you could point to the bug tracker # that would be helpful.
http://moodle.org/bugs/bug.php?op=show&bugid=4945&pos=0
http://moodle.org/bugs/bug.php?op=show&bugid=5249&pos=1
I think the form action should be 'index.php' not 'stats.php', but I'll have a look into this tommorrow.
>I think the code in that function is corerct, but the problem is that you have no data in your stats table.
Seems to me that there should be a clause that accounts for a first pass where the stats table isn't filled or the possibilty that for some reason the stats table is empty, no?
Are you running cron from command line php or from wget/curl?
cron from browser window - admin/cron.php
Also, can you check the mysql error log?
Will look tommorrow, but its a new server with a new administrator so I am not sure.
Thanks.
http://moodle.org/bugs/bug.php?op=show&bugid=4945&pos=0
http://moodle.org/bugs/bug.php?op=show&bugid=5249&pos=1
I think the form action should be 'index.php' not 'stats.php', but I'll have a look into this tommorrow.
>I think the code in that function is corerct, but the problem is that you have no data in your stats table.
Seems to me that there should be a clause that accounts for a first pass where the stats table isn't filled or the possibilty that for some reason the stats table is empty, no?
Are you running cron from command line php or from wget/curl?
cron from browser window - admin/cron.php
Also, can you check the mysql error log?
Will look tommorrow, but its a new server with a new administrator so I am not sure.
Thanks.
> Seems to me that there should be a clause that accounts for a first pass where the
> stats table isn't filled or the possibilty that for some reason the stats table is empty,
> no?
Why? If enablestats is on, and there is no data, it means that (unless there's a problem occuring as in this case, which there shouldn't be!), stats has JUST been set to run, but there's no data. Therefore, stats is in 'catchup mode'.
Bear in mind that if you have a big site, and you want to set stats to start running over ALL the logs, it will take a long time to catch up.
When we first enabled stats in our biggest installation (50,000 users, 10,000 courses and a year of logs), we had it set to run, I think 6 hours a night, and it took about 2 weeks to process all the history and catch up to itself.
This is by no means on a slow server ;)
> cron from browser window - admin/cron.php
You're running it manually? Ok, at any rate if you're running it through the browser, please check your apache error log.
> Will look tommorrow, but its a new server with a new administrator so I am not sure.
Great! Keep me posted.
> stats table isn't filled or the possibilty that for some reason the stats table is empty,
> no?
Why? If enablestats is on, and there is no data, it means that (unless there's a problem occuring as in this case, which there shouldn't be!), stats has JUST been set to run, but there's no data. Therefore, stats is in 'catchup mode'.
Bear in mind that if you have a big site, and you want to set stats to start running over ALL the logs, it will take a long time to catch up.
When we first enabled stats in our biggest installation (50,000 users, 10,000 courses and a year of logs), we had it set to run, I think 6 hours a night, and it took about 2 weeks to process all the history and catch up to itself.
This is by no means on a slow server ;)
> cron from browser window - admin/cron.php
You're running it manually? Ok, at any rate if you're running it through the browser, please check your apache error log.
> Will look tommorrow, but its a new server with a new administrator so I am not sure.
Great! Keep me posted.
Hi Penny,
I installed to the latest version (previously I was working on one I downloaded on the 19th Apr) and it all works.
Thanks for your support!
Paolo
I installed to the latest version (previously I was working on one I downloaded on the 19th Apr) and it all works.
Thanks for your support!
Paolo
Hi Penny,
I have been reading through this post and indeed get the same errors in catchup mode. I have run some of the queries suggested, and was wondering if you would have an idea as to what the issue may be...
I am running moodle 1.6.4 on a Linux server with mysql db...
Regards,
Mark
|
id | name | value | ||
|---|---|---|---|---|---|
|
|
274 | statslastdaily | 1174971610 | |
|
|
|
273 | statsrunning | 0 | |
|
|
|
272 | statsfirstrunlock | 0 | |
|
|
|
271 | statsruntimestartminute | 0 | |
|
|
|
270 | statsruntimestarthour | 11 | |
|
|
|
269 | statsuserthreshold | 0 | |
|
|
|
268 | statsmaxruntime | 28800 | |
|
|
|
267 | statsfirstrun | 7257600 | |
|
|
|
266 | enablestats | 1 | |
|
|
|
275 | statslastweekly | 1171408521 | |
|
|
|
276 | statslastmonthly | 1171940422 | |
|
count(*)
|
|---|
| 0 |
select count(distinct(timeend)) from mdl_stats_daily;
| count(distinct(timeend)) |
|---|
| 0 |
If you search the tracker there are several various statistics catchup bug reports. I still occasionally see my server 2 days behind and am not sure why. It would be nice to get stats working properly where the tabular data matches the graph and the data reported in the Moodle stats table corresponds to the logs for the given dates. There seemed to be some question about how accurate the information was in the statistics tables. Feel free to vote on any of the outstanding bug reports. Peace.
Thanks for the personal support, Penny 
I will run the commands tomorrow and get back to you here (real busy tonight) in case it helps anybody else. Beyond that I will add you to skype and try and get in touch over the next couple of days.
Thanks again
Darren
I will run the commands tomorrow and get back to you here (real busy tonight) in case it helps anybody else. Beyond that I will add you to skype and try and get in touch over the next couple of days.
Thanks again
Darren
Hi all, Penny in particular as she appears to be the guru on this
I have two installs running the latest 1.6 Beta 5 (2006050504) on a linux box running PHP5 and MySql 4.1.14.
Both installs have the problem of being in catchup mode (one says it has processed 9 days with 73 pending, the other 1 day has been processed with 57 pending).
Both have stale lockfiles e.g. for one of them it says:
Any pointers would be much appreciated.
Regards
Harry
I have two installs running the latest 1.6 Beta 5 (2006050504) on a linux box running PHP5 and MySql 4.1.14.
Both installs have the problem of being in catchup mode (one says it has processed 9 days with 73 pending, the other 1 day has been processed with 57 pending).
Both have stale lockfiles e.g. for one of them it says:
STALE LOCKFILE FOR statsrunning - was 1148911980
Running daily statistics gathering...
starting at 1144418400Have run the queries Penny mentioned in other posts in this thread (see attached).
Any pointers would be much appreciated.
Regards
Harry
There certainly seems to be a problem there. For 9 days processed, having 375769 daily records is a bit much.
how many courses do you have?
you say you're running the latest 1.6 beta but is that what you were running when you _started_ running stats?
can you run ps ax | grep cron and paste the output here?
are you running cron with wget or with php cli?
Can you also run
select count(*) from mdl_stats_weekly;
select count(*) from mdl_stats_monthly;
select count(*) from mdl_stats_user_daily;
select count(*) from mdl_stats_user_weekly;
select count(*) from mdl_stats_user_monthly;
how many courses do you have?
you say you're running the latest 1.6 beta but is that what you were running when you _started_ running stats?
can you run ps ax | grep cron and paste the output here?
are you running cron with wget or with php cli?
Can you also run
select count(*) from mdl_stats_weekly;
select count(*) from mdl_stats_monthly;
select count(*) from mdl_stats_user_daily;
select count(*) from mdl_stats_user_weekly;
select count(*) from mdl_stats_user_monthly;
Hi Penny
How's life across the water? Thanks for popping in
The screen shots are actually from the install that has only processed 1 day with 58 pending (guessing that's not good!)
The install in question only has 9 courses and 8 members. Both of the 1.6 installs I have minimal data; one was just to have a look at 1.6 when the beta was first released, this one is just being set up for collabaration between various organisations and as such is not live yet (the courses and members are for demo purposes on Wednesday and have virtually no data in them other than topic headings and a couple of blocks).
Both installs where fresh 1.6 Beta from just before SourceForge went down, both are now up-to-date as of yesterday (been keeping an eye on it to see if any bug fixes would fix it up since initial install but sadly no).
No worries . . . ummmmm . . . can you give me a bit more of a hint on what that means (sorry, a lot of this coding/linux/php/sql stuff is still Greek to me
)
At the moment on these installs just firing them manually, either via the admin page within moodle or direct in the browser (been firing them from the admin page and then half a dozen or so tries direct to see if they would catch up). When setup properly it will be run via php I believe (wget doesn't work on my hosted server, all the current cron jobs I have setup on live Moodle installs and other scripts start with"php -q $HOME/public_html/" etc.)
See below for screen shots of the queries you mentioned . . . in fact no need for an attachment - they are all 0. Was just about to crop them and attach when I noticed the results all being 0?
Regards
Harry
How's life across the water? Thanks for popping in
There certainly seems to be a problem there. For 9 days processed, having 375769 daily records is a bit much.
The screen shots are actually from the install that has only processed 1 day with 58 pending (guessing that's not good!)
how many courses do you have?
The install in question only has 9 courses and 8 members. Both of the 1.6 installs I have minimal data; one was just to have a look at 1.6 when the beta was first released, this one is just being set up for collabaration between various organisations and as such is not live yet (the courses and members are for demo purposes on Wednesday and have virtually no data in them other than topic headings and a couple of blocks).
you say you're running the latest 1.6 beta but is that what you were running when you _started_ running stats?
Both installs where fresh 1.6 Beta from just before SourceForge went down, both are now up-to-date as of yesterday (been keeping an eye on it to see if any bug fixes would fix it up since initial install but sadly no).
can you run ps ax | grep cron and paste the output here?
No worries . . . ummmmm . . . can you give me a bit more of a hint on what that means (sorry, a lot of this coding/linux/php/sql stuff is still Greek to me
)
are you running cron with wget or with php cli?
At the moment on these installs just firing them manually, either via the admin page within moodle or direct in the browser (been firing them from the admin page and then half a dozen or so tries direct to see if they would catch up). When setup properly it will be run via php I believe (wget doesn't work on my hosted server, all the current cron jobs I have setup on live Moodle installs and other scripts start with"php -q $HOME/public_html/" etc.)
See below for screen shots of the queries you mentioned . . . in fact no need for an attachment - they are all 0. Was just about to crop them and attach when I noticed the results all being 0?
Regards
Harry
sounds like something somewhere got stuck in an infinite loop 
I would:
delete from mdl_stats_daily;
delete from mdl_config where name like '%stats%';
and then set your admin options again and try again. I know I fixed an infinite loop bug awhile ago, but I'm worried about the fact you're using php 5.
Do you still have php 4 on your system? try from the command line:
which php4
and if you have that, you can run moodle cron like
php /path/to/admin/cron.php
and that way it won't time out.
I would:
delete from mdl_stats_daily;
delete from mdl_config where name like '%stats%';
and then set your admin options again and try again. I know I fixed an infinite loop bug awhile ago, but I'm worried about the fact you're using php 5.
Do you still have php 4 on your system? try from the command line:
which php4
and if you have that, you can run moodle cron like
php /path/to/admin/cron.php
and that way it won't time out.
Hi Penny
Did the two deletions and fired cron again, same deal - 1 day processed, 58 remaining.
Switched back to PHP 4.4.1 (at my host, both are still running, PHP 4 being default, just added "AddHandler application/x-httpd-php5 .php" to the .htaccess file to switch to PHP 5) and then did the two deletions again, fired cron a few times - same results.
Have my admin options set to:
enablestats = yes
statsfirstrun = all
statsmaxruntime = until complete
statsruntimestart = 00:05
statsuserthreshold = 0
No error logs as far as I can see.
H
Did the two deletions and fired cron again, same deal - 1 day processed, 58 remaining.
Switched back to PHP 4.4.1 (at my host, both are still running, PHP 4 being default, just added "AddHandler application/x-httpd-php5 .php" to the .htaccess file to switch to PHP 5) and then did the two deletions again, fired cron a few times - same results.
Have my admin options set to:
enablestats = yes
statsfirstrun = all
statsmaxruntime = until complete
statsruntimestart = 00:05
statsuserthreshold = 0
No error logs as far as I can see.
H
What is the output to the browser when you run cron? Does it complete?
I will try and reproduce this today if I have time.
Running statistics cron through apache is generally a very bad idea though.
I will try and reproduce this today if I have time.
Running statistics cron through apache is generally a very bad idea though.
in fact, I've just tried this on a fresh 16 install and stats ran through ok..
I really need the output of the FIRST attempt to run cron. Preferably NOT through a browser. Can you run those deletions again and run your cronjob from the command line, and paste the output here or attach it as a file or something?
You should be able to do
(php4 /path/to/cron.php 2>&1) > forpenny.txt
I really need the output of the FIRST attempt to run cron. Preferably NOT through a browser. Can you run those deletions again and run your cronjob from the command line, and paste the output here or attach it as a file or something?
You should be able to do
(php4 /path/to/cron.php 2>&1) > forpenny.txt
Hi Penny
Cron completes fine. At the moment I can't get to the command line (have to look into a way of getting Putty to sneak through the firewall here!) but will do it when I get home and post the results.
Thanks again for you help on this
Regards
Harry
Cron completes fine. At the moment I can't get to the command line (have to look into a way of getting Putty to sneak through the firewall here!) but will do it when I get home and post the results.
Thanks again for you help on this
Regards
Harry
I'm running Moodle 1.6 Beta 5, mysql 5.0.18, php 5.1.2 Windows 2003 running IIS and stats are not processing
I've no results in SQL, CRON logs show no processing of Stat jobs
I've set the variable for one week and any class with 1 or more members.
I've no idea what to look at now.
We ran into a similar problem with the stats when upgrading from 1.5 to 1.6 (the final release) except that the stats page would always been in catchup mode and be at 0 of x days. By looking at the output of the cron script, I found that it was throwing an error when it checked for lib.php within each module. We had an old module installed (exercise to be precise) that I had forgotten about, and since it didn't have a lib.php file the stats script would throw an error and abort when it reached that module. The main problem was that after the first time that error occurred the stats would never run again; the cron script would run fine but it never touched the stats portion which left it continually at 0 of x days in catchup mode.
The solution was to completely delete the exercise module to eliminate it as the problem and then run the SQL delete commands listed above:
That reset the stats data so that it started over from scratch and since then the stats have been running just fine. I don't know if this is the exact issue that other people have experienced, but I thought I'd mention it in case someone else is in a similar situation.
The solution was to completely delete the exercise module to eliminate it as the problem and then run the SQL delete commands listed above:
delete from mdl_stats_daily;
delete from mdl_config where name like '%stats%';
delete from mdl_config where name like '%stats%';
That reset the stats data so that it started over from scratch and since then the stats have been running just fine. I don't know if this is the exact issue that other people have experienced, but I thought I'd mention it in case someone else is in a similar situation.
Hi
I have got stats to work in the reports menu but the problem lies now with the same appearing for the individual on the Activity Reports section under the Statistics tab. The image does not show up in this section and the moodle installtion is version 1.6. If I right click i get the page name as statsgraph.php. Can someone tell me what this should be and actuall the path to this page is /course/statsgraph.php but this page does not exist in the said location. Can someone point me in the direction to set this right and where to configure this missing page???
Regards
Uday
It seems that I've found an answer to your question while looking around.
- It's Bug #6042 - Fixed in Moodle 1.6.1+
- http://moodle.org/bugs/bug.php?op=show&bugid=6042&pos=7
- It's Bug #6042 - Fixed in Moodle 1.6.1+
- http://moodle.org/bugs/bug.php?op=show&bugid=6042&pos=7
Excellent- this was my problem too and Window environment gives poor logging so didn't detect this event. I removed excercise module and all is working. Sould really be part of Moodle - a section to display errors of installs. Thanks Jason