Error when purging puppet reports

Support
1

I am trying to purge some puppet reports following the guide @
http://theforeman.org/projects/foreman/wiki/Puppet_Reports

I have never purged reports before since I've started using foreman
probably about 6 months ago and we now have 4000+ systems reporting every
30 min. So there are LOTS of reports …

The first time I ran the command and received an error it looked like:

rake18 reports:expire days=7 status=0 RAILS_ENV="production"
(in /srv/www/usps-puppet-foreman)
rake aborted!
Mysql::Error: Got a packet bigger than 'max_allowed_packet' bytes: SELECT
id FROM reports WHERE (reports.id IN
(3,4,6,7,8,9,10,11,12,13,17,18,89,139,142,148,151,188,199,1386,1388,1416,1429,1436,1437,1445,…

I then increased the max_allowed_packet on the mysql server and ran it
again now with the following error:

rake18 reports:expire days=7 status=0 RAILS_ENV="production"
(in /srv/www/usps-puppet-foreman)
rake aborted!
Mysql::Error: Out of memory (Needed 2304288 bytes): SELECT id FROM
reports WHERE (reports.id IN
(3,4,6,7,8,9,10,11,12,13,17,18,89,139,142,148,151,188,199,1386,1388,1416,1429,1436,1437,1445,1446,1447,1451,1455,1458,1460,1463,1466,1471,1478,1479,1485,1490,1496,1497,1498,1511,1512,1519,1520,1527,1531,1896,1901,1903,1905,1912,1915,2441,2445,2449,2451,2455,2462,3106,3589,3590,3593,3598,3601,3605,3608,3611,3612,3624,6169,6224,6229,6232,6235,6236,6245,6246,6249,6256,6278,6293,6311,6315,6316,6339,6342,6344,6347,6348,6350,6353,6360,6361,6363,6365
…

Any tips on how to get past this? I promise to then run it weekly so that
the queries do not get so large again. :stuck_out_tongue:

Thanks!
Jake

2

Maybe start with days=180 and work your way down to 7?

3

Thanks for the reply. I've already tried days=360 actually but it seems to
still parse all reports and causes the Mysql::Error: Out of memory (Needed
2304288 bytes): still. I'm looking at the memory settings on my mysql
server right now as I see in the mysqld.log file the same OutOfMemory
errors. However, not sure exactly what to tune to address this specific
issue so I'm kind of blindly setting/increasing values …

If anyone has some tips I'd be more then happy to hear them!

Thanks,
Jake

··· On Friday, March 2, 2012 10:43:35 AM UTC-6, Adam Heinz wrote: > > Maybe start with days=180 and work your way down to 7? >
4

So I got this to work finally. After getting mysql to not throw errors
anymore I was then running into memory issues on the system I was running
rake on in that it would swap. I needed to up the system from 4GB to
16GB (had issues with 8 GB as well) before the rake command would run
without swapping.

Regards,
Jake

··· On Friday, March 2, 2012 11:11:31 AM UTC-6, jmccann wrote: > > Thanks for the reply. I've already tried days=360 actually but it seems > to still parse all reports and causes the Mysql::Error: Out of memory > (Needed 2304288 bytes): still. I'm looking at the memory settings on my > mysql server right now as I see in the mysqld.log file the same OutOfMemory > errors. However, not sure exactly what to tune to address this specific > issue so I'm kind of blindly setting/increasing values ... > > If anyone has some tips I'd be more then happy to hear them! > > Thanks, > Jake > > On Friday, March 2, 2012 10:43:35 AM UTC-6, Adam Heinz wrote: >> >> Maybe start with days=180 and work your way down to 7? >> >
5

Hmmm… it seems to me we need to figure out how to optimize this for
systems with less RAM.

Thoughts?

Thanks,
Brian

··· On Fri, Mar 2, 2012 at 3:22 PM, jmccann wrote:

So I got this to work finally. After getting mysql to not throw errors
anymore I was then running into memory issues on the system I was running
rake on in that it would swap. I needed to up the system from 4GB to
16GB (had issues with 8 GB as well) before the rake command would run
without swapping.

Regards,
Jake

On Friday, March 2, 2012 11:11:31 AM UTC-6, jmccann wrote:

Thanks for the reply. I’ve already tried days=360 actually but it seems
to still parse all reports and causes the Mysql::Error: Out of memory
(Needed 2304288 bytes): still. I’m looking at the memory settings on my
mysql server right now as I see in the mysqld.log file the same OutOfMemory
errors. However, not sure exactly what to tune to address this specific
issue so I’m kind of blindly setting/increasing values …

If anyone has some tips I’d be more then happy to hear them!

Thanks,
Jake

On Friday, March 2, 2012 10:43:35 AM UTC-6, Adam Heinz wrote:

Maybe start with days=180 and work your way down to 7?

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/fvDxwjmEhFQJ.

To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
http://aws.amazon.com/solutions/solution-providers/brandorr/

6

Hi,

Sorry for following up only now, but which version of foreman are you
using? I was under the impression that we already resolved this issue
at Bug #687: rake reports:expire abuses memory and network bandwidth - Foreman.

I must admit i didnt have such a large data set to test on (4000
nodes * 180 days * 24 hours * 48 puppet runs per day).

btw: out of curiosity, how large was the db vs now, how were the
performance, did you see any major difference after deleting the
reports?

if you have a backup of the db, we could try to experiment and
optimize further the deletion process.
Ohad

··· On Fri, Mar 2, 2012 at 10:22 PM, jmccann wrote: > So I got this to work finally. After getting mysql to not throw errors > anymore I was then running into memory issues on the system I was running > rake on in that it would swap. I needed to up the system from 4GB to > 16GB (had issues with 8 GB as well) before the rake command would run > without swapping. > > Regards, > Jake > > > On Friday, March 2, 2012 11:11:31 AM UTC-6, jmccann wrote: >> >> Thanks for the reply. I've already tried days=360 actually but it seems >> to still parse all reports and causes the Mysql::Error: Out of memory >> (Needed 2304288 bytes): still. I'm looking at the memory settings on my >> mysql server right now as I see in the mysqld.log file the same OutOfMemory >> errors. However, not sure exactly what to tune to address this specific >> issue so I'm kind of blindly setting/increasing values ... >> >> If anyone has some tips I'd be more then happy to hear them! >> >> Thanks, >> Jake >> >> On Friday, March 2, 2012 10:43:35 AM UTC-6, Adam Heinz wrote: >>> >>> Maybe start with days=180 and work your way down to 7? > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/foreman-users/-/fvDxwjmEhFQJ. > > To post to this group, send email to foreman-users@googlegroups.com. > To unsubscribe from this group, send email to > foreman-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/foreman-users?hl=en.
7

Ohad,

I was able to get it to complete once. But then started having issues
again. So while some of the data may have been purged, I am still
encountering issues. Also, I only purged 'inactive' reports and would like
to purge some active reports as well.

I am currently out of the office this week. I'll be back 3/12 and would
like to look at this more. Let me anything you'd like me to check/do when
I get back.

I don't currently have an accessible backup of the DB … but I wouldn't
mind making one before doing anymore testing.

The performance was very slow (bout 20 min running before getting an error)
and as I said a lot of memory was used on the DB server as well as the
server I was running rake on … but I guess I'm not sure what is to be
expected as well, so maybe what seems to be a lot to me really isn't … :stuck_out_tongue:

Thanks,
Jake

8

Ohad,

So a question I have is when I run: rake18 reports:expire days=7 status=0
RAILS_ENV="production" why it takes ~20 min. to fail … especially since I
have no reports with a status of 0 (I guess …)

> select id from reports where status=0;
Empty set (0.00 sec)

··· > select id from reports where status=1 limit 10; +-------+ > id | +-------+ > 89 | > 1458 | > 1463 | > 3601 | > 3624 | > 6315 | > 10419 | > 10575 | > 18722 | > 19427 | +-------+ 10 rows in set (0.00 sec)

I would think the reports:expire shouldn’t take very long to run on a set
of conditions that do not match many (in this case any) reports.

Thanks,
Jake

9

I'm back in the office and ready to work on this some more.

The filesystem that mysql DB files are on is at 9.6G. I don't know if that
is a good means of checking the DB size, I'm not a mysql specialist. :wink:

As for making a backup, I don't mind doing that before proceeding. Do I
just take a mysqldump and set this up on another system to hit basically?
Or some other process would be better? Have instructions/links?

Thanks,
Jake

Let me know if making a copy of the DB

··· On Wednesday, March 7, 2012 10:36:27 AM UTC-6, jmccann wrote: > > Ohad, > > I was able to get it to complete once. But then started having issues > again. So while some of the data may have been purged, I am still > encountering issues. Also, I only purged 'inactive' reports and would like > to purge some active reports as well. > > I am currently out of the office this week. I'll be back 3/12 and would > like to look at this more. Let me anything you'd like me to check/do when > I get back. > > I don't currently have an accessible backup of the DB ... but I wouldn't > mind making one before doing anymore testing. > > The performance was very slow (bout 20 min running before getting an > error) and as I said a lot of memory was used on the DB server as well as > the server I was running rake on ... but I guess I'm not sure what is to be > expected as well, so maybe what seems to be a lot to me really isn't ... :P > > Thanks, > Jake >
10

btw, the reports tables currently has 14 million+ rows in it …

Thanks,
Jake

11

> Ohad,
>
> So a question I have is when I run: rake18 reports:expire days=7 status=0 RAILS_ENV="production" why it takes ~20 min. to fail … especially since I have no reports with a status of 0 (I guess …)
>
> > select id from reports where status=0;
> Empty set (0.00 sec)
>
> > select id from reports where status=1 limit 10;
> ±------+
> > id |
> ±------+
> > 89 |
> > 1458 |
> > 1463 |
> > 3601 |
> > 3624 |
> > 6315 |
> > 10419 |
> > 10575 |
> > 18722 |
> > 19427 |
> ±------+
> 10 rows in set (0.00 sec)
>
> I would think the reports:expire shouldn't take very long to run on a set of conditions that do not match many (in this case any) reports.

··· On Mar 19, 2012, at 1:03 PM, jmccann wrote: ---- logs are your friend... cd FOREMAN_BASE_DIRECTORY less logs/production.log

but you can manipulate directly in ruby console

cd FOREMAN_BASE_DIRECTORY

mimic some of the code in app/models/report.rb (specifically, look at 'self.expire(conditions {})

here’s a really simplistic idea

purge_begin = '02/01/2012’
purge_end = ‘02/29/2012’

reports = >> Report.find(:all, :conditions => [“created_at > ? AND created_at < ?”, purge_begin.to_time, purge_end.to_time], :select => id)

purgeme.each do |reports|
report_ids = reports.map &:id
Log.delete_all({:report_id => report_ids})
count += Report.delete_all({:id => report_ids})
end
puts count + " Reports have been deleted"

Craig

12

Yikes!

did you try "Drop table reports"? Just kidding, don't do that.

Someone else had a similar problem, have you searched the archives?

Corey Osman
corey@logicminds.biz

Green IT and Datacenter Automation Specialist

··· On Mar 19, 2012, at 1:09 PM, jmccann wrote:

btw, the reports tables currently has 14 million+ rows in it …

Thanks,
Jake

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To view this discussion on the web visit https://groups.google.com/d/msg/foreman-users/-/vFROt-75RbwJ.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en.

13

Craig,

Thanks for the reply, but you lost me. :frowning: Happy to check the logs, but
not sure what for. And happy to mimic code and create my own purge if I
have to, but I'm guessing this should just be working … which is does
seems to (more testing today) if I use the code that existed previous to
the existing block that uses 'find_in_batches'. So let me know what you
are trying to accomplish with your suggestions.

Thanks,
Jake

··· On Monday, March 19, 2012 4:17:26 PM UTC-5, Craig White wrote: > > > On Mar 19, 2012, at 1:03 PM, jmccann wrote: > > > Ohad, > > > > So a question I have is when I run: rake18 reports:expire days=7 > status=0 RAILS_ENV="production" why it takes ~20 min. to fail ... > especially since I have no reports with a status of 0 (I guess ...) > > > > > select id from reports where status=0; > > Empty set (0.00 sec) > > > > > select id from reports where status=1 limit 10; > > +-------+ > > > id | > > +-------+ > > > 89 | > > > 1458 | > > > 1463 | > > > 3601 | > > > 3624 | > > > 6315 | > > > 10419 | > > > 10575 | > > > 18722 | > > > 19427 | > > +-------+ > > 10 rows in set (0.00 sec) > > > > I would think the reports:expire shouldn't take very long to run on a > set of conditions that do not match many (in this case any) reports. > ---- > logs are your friend... > cd FOREMAN_BASE_DIRECTORY > less logs/production.log > > but you can manipulate directly in ruby console > > cd FOREMAN_BASE_DIRECTORY > > mimic some of the code in app/models/report.rb (specifically, look at > 'self.expire(conditions {}) > > here's a really simplistic idea > > purge_begin = '02/01/2012' > purge_end = '02/29/2012' > > reports = >> Report.find(:all, :conditions => ["created_at > ? AND > created_at < ?", purge_begin.to_time, purge_end.to_time], :select => id) > > purgeme.each do |reports| > report_ids = reports.map &:id > Log.delete_all({:report_id => report_ids}) > count += Report.delete_all({:id => report_ids}) > end > puts count + " Reports have been deleted" > > Craig > >
14

So I reverted from the 'find in batches' code to what is was before … and
it seems to run a lot better:

So I reverted the code to when it didn't use 'find in batches' and:

time rake18 reports:expire days=7 status=0 RAILS_ENV="production"
(in /srv/www/usps-puppet-foreman)

real 0m6.828s
user 0m5.704s
sys 0m1.008s

So the old method seems to maybe work better in my condition.

My next question is I know status 0 is an inactive report. Is there an
easy way to know what other status codes are and what they represent? If
there is not an easy way, can someone tell me what a status would be for a
server that has skipped resources only? I have scheduled resources so for
me an inactive run is more like a run that has a value in 'skipped':

about 8 hours ago 0 0 0 0 6 Destroy
about 9 hours ago 0 0 0 0 6 Destroy

Thanks,
Jake

15

> Craig,
>
> Thanks for the reply, but you lost me. :frowning: Happy to check the logs, but not sure what for. And happy to mimic code and create my own purge if I have to, but I'm guessing this should just be working … which is does seems to (more testing today) if I use the code that existed previous to the existing block that uses 'find_in_batches'. So let me know what you are trying to accomplish with your suggestions.
>
> Thanks,
> Jake
>
>
> > Ohad,
> >
> > So a question I have is when I run: rake18 reports:expire days=7 status=0 RAILS_ENV="production" why it takes ~20 min. to fail … especially since I have no reports with a status of 0 (I guess …)
> >
> > > select id from reports where status=0;
> > Empty set (0.00 sec)
> >
> > > select id from reports where status=1 limit 10;
> > ±------+
> > > id |
> > ±------+
> > > 89 |
> > > 1458 |
> > > 1463 |
> > > 3601 |
> > > 3624 |
> > > 6315 |
> > > 10419 |
> > > 10575 |
> > > 18722 |
> > > 19427 |
> > ±------+
> > 10 rows in set (0.00 sec)
> >
> > I would think the reports:expire shouldn't take very long to run on a set of conditions that do not match many (in this case any) reports.
> ----
> logs are your friend…
> cd FOREMAN_BASE_DIRECTORY
> less logs/production.log
>
> but you can manipulate directly in ruby console
>
> cd FOREMAN_BASE_DIRECTORY
>
> mimic some of the code in app/models/report.rb (specifically, look at 'self.expire(conditions {})
>
> here's a really simplistic idea
>
> purge_begin = '02/01/2012'
> purge_end = '02/29/2012'
>
> reports = >> Report.find(:all, :conditions => ["created_at > ? AND created_at < ?", purge_begin.to_time, purge_end.to_time], :select => id)
>
> purgeme.each do |reports|
> report_ids = reports.map &:id
> Log.delete_all({:report_id => report_ids})
> count += Report.delete_all({:id => report_ids})
> end
> puts count + " Reports have been deleted"

··· On Mar 20, 2012, at 6:29 AM, jmccann wrote: > On Monday, March 19, 2012 4:17:26 PM UTC-5, Craig White wrote: > On Mar 19, 2012, at 1:03 PM, jmccann wrote: ---- Sorry, I did have a typo but I thought you would figure it out.

cd FOREMAN_ROOT_DIRECTORY

opens an interactive ruby console from which you can manipulate the

ruby Models directly

script/console production

sets a short range of reports to be selected for deletion…

purge_begin = '02/01/2012’
purge_end = ‘02/29/2012’

finds those reports

purgeme = >> Report.find(:all, :conditions => [“created_at > ? AND created_at < ?”,
purge_begin.to_time, purge_end.to_time], :select => id)

liberally borrowed from ‘reports’ model in Foreman that I gather

takes the list of reports found in the step above,

deletes the Log table records associated with those reports

deletes the reports table records identified above

and finally reports how many ‘reports’ it deleted.

purgeme.each do |reports|
report_ids = reports.map &:id
Log.delete_all({:report_id => report_ids})
count += Report.delete_all({:id => report_ids})
end
puts count + " Reports have been deleted"

This allows you the mechanics to selectively delete specific ranges of reports. (doing in batches allows you to avoid massive memory allocations when selecting a LOT of reports for deletion).

Thus you can go month by month - changing the purge_begin & purge_end variables, execute the find, and finally do the purging.

Craig

16

It wasn't that I didn't understand the code, I was trying to figure out how
you were trying to help me. I now get that you are trying to get it so I
can define more precisely a (small) range to delete reports in, thus trying
to reduce the memory in deleting them … loop through ranges till I catch
up on cleanup.

Thanks,
Jake

··· On Tuesday, March 20, 2012 1:25:34 PM UTC-5, Craig White wrote: > > > On Mar 20, 2012, at 6:29 AM, jmccann wrote: > > > Craig, > > > > Thanks for the reply, but you lost me. :( Happy to check the logs, but > not sure what for. And happy to mimic code and create my own purge if I > have to, but I'm guessing this should just be working ... which is does > seems to (more testing today) if I use the code that existed previous to > the existing block that uses 'find_in_batches'. So let me know what you > are trying to accomplish with your suggestions. > > > > Thanks, > > Jake > > > > On Monday, March 19, 2012 4:17:26 PM UTC-5, Craig White wrote: > > > > On Mar 19, 2012, at 1:03 PM, jmccann wrote: > > > Ohad, > > > > > > So a question I have is when I run: rake18 reports:expire days=7 > status=0 RAILS_ENV="production" why it takes ~20 min. to fail ... > especially since I have no reports with a status of 0 (I guess ...) > > > > > > > select id from reports where status=0; > > > Empty set (0.00 sec) > > > > > > > select id from reports where status=1 limit 10; > > > +-------+ > > > > id | > > > +-------+ > > > > 89 | > > > > 1458 | > > > > 1463 | > > > > 3601 | > > > > 3624 | > > > > 6315 | > > > > 10419 | > > > > 10575 | > > > > 18722 | > > > > 19427 | > > > +-------+ > > > 10 rows in set (0.00 sec) > > > > > > I would think the reports:expire shouldn't take very long to run on a > set of conditions that do not match many (in this case any) reports. > > ---- > > logs are your friend... > > cd FOREMAN_BASE_DIRECTORY > > less logs/production.log > > > > but you can manipulate directly in ruby console > > > > cd FOREMAN_BASE_DIRECTORY > > > > mimic some of the code in app/models/report.rb (specifically, look at > 'self.expire(conditions {}) > > > > here's a really simplistic idea > > > > purge_begin = '02/01/2012' > > purge_end = '02/29/2012' > > > > reports = >> Report.find(:all, :conditions => ["created_at > ? AND > created_at < ?", purge_begin.to_time, purge_end.to_time], :select => id) > > > > purgeme.each do |reports| > > report_ids = reports.map &:id > > Log.delete_all({:report_id => report_ids}) > > count += Report.delete_all({:id => report_ids}) > > end > > puts count + " Reports have been deleted" > ---- > Sorry, I did have a typo but I thought you would figure it out. > > cd FOREMAN_ROOT_DIRECTORY > # opens an interactive ruby console from which you can manipulate the > # ruby Models directly > script/console production > > # sets a short range of reports to be selected for deletion... > purge_begin = '02/01/2012' > purge_end = '02/29/2012' > > # finds those reports > purgeme = >> Report.find(:all, :conditions => ["created_at > ? AND > created_at < ?", \ > purge_begin.to_time, purge_end.to_time], :select => id) > > # liberally borrowed from 'reports' model in Foreman that I gather > # takes the list of reports found in the step above, > # deletes the Log table records associated with those reports > # deletes the reports table records identified above > # and finally reports how many 'reports' it deleted. > purgeme.each do |reports| > report_ids = reports.map &:id > Log.delete_all({:report_id => report_ids}) > count += Report.delete_all({:id => report_ids}) > end > puts count + " Reports have been deleted" > > This allows you the mechanics to selectively delete specific ranges of > reports. (doing in batches allows you to avoid massive memory allocations > when selecting a LOT of reports for deletion). > > Thus you can go month by month - changing the purge_begin & purge_end > variables, execute the find, and finally do the purging. > > Craig > >
17

> So I reverted from the 'find in batches' code to what is was before … and
> it seems to run a lot better:

Thats interesting,
the idea of find in batches, is simply not to load of all the data
into memory, and simply load each time up to 1000 reports into memory,
because otherwise you would need to keep all of the data in memory.

is there a chance you can enable debug mode, and share the logs?

>
> So I reverted the code to when it didn't use 'find in batches' and:
>
> time rake18 reports:expire days=7 status=0 RAILS_ENV="production"
> (in /srv/www/usps-puppet-foreman)
>
> real 0m6.828s
> user 0m5.704s
> sys 0m1.008s
>
> So the old method seems to maybe work better in my condition.
>
> My next question is I know status 0 is an inactive report. Is there an easy
> way to know what other status codes are and what they represent? If there
> is not an easy way, can someone tell me what a status would be for a server
> that has skipped resources only? I have scheduled resources so for me an
> inactive run is more like a run that has a value in 'skipped':

in order to store the reports data efficiently, we store bitwize
values in the status, so really, you need to break it into bits, and
each set of bits (afair 5) store a different value.

looking at the report.rb and report_common files probably can shed
some more light on the implementation.

··· On Mon, Mar 19, 2012 at 11:07 PM, jmccann wrote:

about 8 hours ago 0 0 0 0 6 Destroy
about 9 hours ago 0 0 0 0 6 Destroy

Thanks,
Jake

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/wEBTxXVaK44J.

To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

18

Ohad,

This only worked better for me when so far doing status=0 for now, probably
as I have no reports with status of 0. Maybe when I try to do it with the
other status I am looking for I will again run into some kind of issue.

I will enable debugging before I do anything more and provide results.

Thanks,
Jake

··· >
19

Ohad,
>
> I've enabled debug and snipped out the section in the log that I think
pertains to this. Let me know if I snipped too much.

So not using 'find in batches' I did: rake18 reports:expire days=300
RAILS_ENV="production" and it deleted some older reports! It took about 45
seconds to run and I didn't see any crazy memory utilization (maybe because
not a ton was deleted?)

Here is output from 'rake18 reports:expire days=280 RAILS_ENV="production"'
after having run 'rake18 reports:expire days=290 RAILS_ENV="production"',
so deleting 10 days of data from a time I didn't have many systems
reporting yet.

http://pastebin.com/NmkZYSGL

Let me know if there is anything else that could help.

Thanks,
Jake

··· On Tuesday, March 20, 2012 1:57:58 PM UTC-5, jmccann wrote: > > Ohad, > > This only worked better for me when so far doing status=0 for now, > probably as I have no reports with status of 0. Maybe when I try to do it > with the other status I am looking for I will again run into some kind of > issue. > > I will enable debugging before I do anything more and provide results. > > Thanks, > Jake > >> On Tuesday, March 20, 2012 1:57:58 PM UTC-5, jmccann wrote: > > Ohad, > > This only worked better for me when so far doing status=0 for now, > probably as I have no reports with status of 0. Maybe when I try to do it > with the other status I am looking for I will again run into some kind of > issue. > > I will enable debugging before I do anything more and provide results. > > Thanks, > Jake > >> On Tuesday, March 20, 2012 1:57:58 PM UTC-5, jmccann wrote: > > Ohad, > > This only worked better for me when so far doing status=0 for now, > probably as I have no reports with status of 0. Maybe when I try to do it > with the other status I am looking for I will again run into some kind of > issue. > > I will enable debugging before I do anything more and provide results. > > Thanks, > Jake > >>
20

Also, I want to apologize that I keep forgetting to delete the previous
comments …
>
> Thanks again!
Jake