Pocket Queries - Why Aren't They Running?

[+Blaze_au]

Has anyone else had problems with the pocket queries running?

 

I have 3 queries which run each day to show caches in my local area. They haven't ran in the last 4 days.

 

Is there a problem? Or am I not getting what I paid for?

[Jeremy]

There's a thread farther down the page about it. The short of it is create a new query if you need it for caching. We're aware of the problem but you can still get your queries same day if you need one for caching.

[WH]

I create my queries on an as needed basis and usually get them within 2 minutes of clicking submit.

[+sbell111]

I get mine every Thursaday, whether I used the last one or not.

[+Cache Viking]

interesting I keep reading about this problem but am not experienceing it myself. I got my regular 4 for Friday already and the two for yesterday as well as the two for Wednesday.

[Jeremy]

It only tends to happen to people who run their query every day. The PQ page explains it but the gist is the more often you run the query the farther back in the queue it goes. So a brand new query runs almost immediately, a 7 day old query runs early in the day, and a daily query gets kicked farther back (and currently doesn't show up).

 

We have added the functionality where a query unchecks itself so many queries that aren't being used at all will slowly drop off the list. From doing DB queries I expect some improvement a week from today with many daily (or multi-day) queries. However I have also been testing all kinds of ideas to run them faster. It's a hard nut to crack.

[+Corp Of Discovery]

It only tends to happen to people who run their query every day. The PQ page explains it but the gist is the more often you run the query the farther back in the queue it goes. So a brand new query runs almost immediately, a 7 day old query runs early in the day, and a daily query gets kicked farther back (and currently doesn't show up).

 

We have added the functionality where a query unchecks itself so many queries that aren't being used at all will slowly drop off the list. From doing DB queries I expect some improvement a week from today with many daily (or multi-day) queries. However I have also been testing all kinds of ideas to run them faster. It's a hard nut to crack.

Tough nuts indeed.

[+Muirwoody]

We have added the functionality where a query unchecks itself so many queries that aren't being used at all will slowly drop off the list. From doing DB queries I expect some improvement a week from today with many daily (or multi-day) queries. However I have also been testing all kinds of ideas to run them faster. It's a hard nut to crack.

Probably a silly question but...OK, I got a PQ today with a note on the email telling me to click the link at the bottom to run the PQ next week. So does that mean click it now? Or click it when I want to run it next week? Thanks

[+beejay&esskay]

We have added the functionality where a query unchecks itself 

Probably a silly question but...OK, I got a PQ today with a note on the email telling me to click the link at the bottom to run the PQ next week. So does that mean click it now? Or click it when I want to run it next week? Thanks

Either, I think. That link takes you to your PQs. Since it has now be unselected, you just need to reselect the day you want it to run before that day.

[Jeremy]

Probably a silly question but...OK, I got a PQ today with a note on the email telling me to click the link at the bottom to run the PQ next week. So does that mean click it now? Or click it when I want to run it next week? Thanks

I didn't think of it that way. You can click on it at any time from now until next Friday. I'll look at that text again.

[+CompuCash]

Probably a silly question but...OK, I got a PQ today with a note on the email telling me to click the link at the bottom to run the PQ next week. So does that mean click it now? Or click it when I want to run it next week? Thanks

I didn't think of it that way. You can click on it at any time from now until next Friday. I'll look at that text again.

 

HA!

 

Interesting interpretation - and correct also.

 

A simple addition of the work NOW would do it (click now if you want to run it next week)

 

but like J said - doesn't really matter when. You can also just go to your PQ page and re-check the box for the day it is supposed to run.

 

Interesting piece of programming there. Must have taken a while - gotta give you credit for taking the time for that - I might have just said go to your PQ page and check the box to run it again.

 

Hey Jeremy - is this having the intended relief to the server? Interested people want to know - and so do I.

 

cc\

Edited August 13, 2005 by CompuCash

[Jeremy]

Hey Jeremy - is this having the intended relief to the server? Interested people want to know - and so do I.

 

cc\

Well, if I do my math right, I won't know whether it will work in practice until it starts working in practice next week. If you know a noticeable improvement next week you'll know then.

[+Hemlock]

Interesting piece of programming there.  Must have taken a while - gotta give you credit for taking the time for that - I might have just said go to your PQ page and check the box to run it again.

The neat thing is, the link in the email is exactly the same URL as the checkbox (for that PQ on that day) on the Pocket Query page. So the only change was to the code was to automatically disable the PQ after it runs, and add that link to the email. Very clever.

 

Here's my suggested text for the email:

This Pocket Query has been automatically disabled. To re-enable it for next week, click this link:

http: //www.geocaching.com/pocket/?pq=blahblahblah

[+CompuCash]

Hey Jeremy - is this having the intended relief to the server?  Interested people want to know - and so do I.

 

cc\

Well, if I do my math right, I won't know whether it will work in practice until it starts working in practice next week. If you know a noticeable improvement next week you'll know then.

 

DUH!

 

yer right - we won't know for a week will we?

 

Gee - why didn't I think of that!

 

cc\

[+CompuCash]

Interesting piece of programming there.  Must have taken a while - gotta give you credit for taking the time for that - I might have just said go to your PQ page and check the box to run it again.

The neat thing is, the link in the email is exactly the same URL as the checkbox (for that PQ on that day) on the Pocket Query page. So the only change was to the code was to automatically disable the PQ after it runs, and add that link to the email. Very clever.

 

Here's my suggested text for the email:

This Pocket Query has been automatically disabled. To re-enable it for next week, click this link:

http: //www.geocaching.com/pocket/?pq=blahblahblah

 

ya that is pretty neat -

 

and I like your wording too ---

 

guess we'll have to wait for our next scheduled PQ to see what it says -

 

cc\

[+DomHeknows]

We have added the functionality where a query unchecks itself 

Probably a silly question but...OK, I got a PQ today with a note on the email telling me to click the link at the bottom to run the PQ next week. So does that mean click it now? Or click it when I want to run it next week? Thanks

Thats all very well and good, but if you use gsak then you don't need to read the email as gsak does it all. That means you could miss this note and then not get your queries.

Not a good solution.

[+robert]

Thats all very well and good, but if you use gsak then you don't need to read the email as gsak does it all. That means you could miss this note and then not get your queries.

Not a good solution.

Your best bet then would be to go to http://www.geocaching.com/pocket once a week to re-enable your PQs.

 

I don't think it's a permanent "solution", just a temporary fix to let some PQs drop out that are in the queue week-after-week that don't need to be for whatever reason. At least that's the impression I got from reading the threads about it.

[+CompuCash]

back to the original topic -

 

the PQ's ARE running - they are just not running the way we want them to.

 

I get at least one every day.

Have not missed one all week.

 

some days I even get 2 - got 2 on Friday.

now one of them has not run since last Wed.

 

After reading one of Jeremy's comments I tried an experiment

and changed all of my pq requests and they seem to be regular.

 

cc\

[Jeremy]

Not a good solution.

Yes. GSAK is not a good solution. It gives you bad habits.

 

And yes. It is a temporary "fix" until we can get them sped up again.

[+gnbrotz]

Yes. GSAK is not a good solution. It gives you bad habits.

I rarely speak out against the mods or TPTB because even when I don't agree with them, I know they have a difficult job and wouldn't/don't want to be in their shoes.

 

That being said, I'm going to respectfully disagree with the quoted statement.

 

When this site's features work as they were designed to, GSAK is an excellent solution when it comes to efficient cache planning.

 

I don't see how automating things to make it easier for the end user equates to bad habits. These methods have been designed to operate within the site's terms of use, and ultimately have no effect on site performance (aside from the actual generation of the PQs). Perhaps PQs are a 'bad habit' too, since they save me plucking away at individual cache pages and/or printing reams of paper that are very soon outdated.

 

I understand the current problem, and appreciate the efforts being made to correct it. Fortunately, it doesn't affect my personal routine significantly. It seemed to me that the stated concerns were done in an appropriate fashion and civil tone, unlike many posts that contain complaints. I expect my pocket queries to contain one thing: the data I requested. If there is new information as it relates to site performace, I think it should be sent under separate cover.

[+Team DEMP]

Yes. GSAK is not a good solution. It gives you bad habits.

What? Did you make a typo?

 

How could GSAK possibly give anyone a bad habit? If anything you should be thanking your lucky stars for GSAK as it has to significantly reduce the load on the GC.com servers.

 

As an example, I almost NEVER use GC.com to find caches. If I didn't have GSAK, I'd be spending all my time on GC.com clicking the "Nearest caches I haven't found" links on cache pages. Instead, in GSAK, I right click a cache, set it as the center point and can visually see all the caches immediately and how far they are from the selected cache at NO COST per transaction to GC.com

 

Add to it the ability for me to, with 1 click, go to the Log a find page for a cache without having to bring up 3 or 4 pages on GC.com, it further reduces the load on the GC.com servers.

 

Are upset that you aren't getting as many page views or advertising impressions because GSAK provides the offline functionality I used to spend time doing online (and suffering with slow page loads for a long time)?

 

You have to explain yourself on that comment.

[+The Leprechauns]

There are any number of prior threads where Jeremy explains the logic behind "bad habits." If I'm recalling his posts correctly, it has to do with the reliance upon stale offline data as opposed to always checking the source -- Geocaching.com -- for current data.

 

I do not use GSAK. I use Watcher, and I simply download a new query or two before each geocaching trip. It works for me, and my data is always current. Not everyone feels the need to construct vast offline copies of the cache database.

[+Team DEMP]

There are any number of prior threads where Jeremy explains the logic behind "bad habits." If I'm recalling his posts correctly, it has to do with the reliance upon stale offline data as opposed to always checking the source -- Geocaching.com -- for current data.

 

I do not use GSAK. I use Watcher, and I simply download a new query or two before each geocaching trip. It works for me, and my data is always current. Not everyone feels the need to construct vast offline copies of the cache database.

If I wanted, I could download a new query and my offline version is just as fresh as your Watcher data, but I don't think that could be the issue here. The info on any cache is no more then 1 day old (well if gc.com could actually send me the PQ I scheduled). How is that "stale"?

 

I can keep track of so much information in GSAK that GC.com doesn't permit me to do from something as simple as which cache was my 276th to something more complex like what are the coords for the 2nd stage of a 4 stage multi I haven't completed.

 

I can in 1 click export all the caches I've selected for a day to GPX & synced to my PocketPC, transfered to my Garmin and the condensed printout out created as a backup to be printed. That used to take me an enormous amount of time clicking away on gc.com.

 

I don't think your explanation of Jeremy's issue will suffice in this case.

[+The Leprechauns]

I don't think your explanation of Jeremy's issue will suffice in this case.

I'm sorry you feel that way. Regardless, it is my God-given right as a sycophantic blind toadie yes-man to spit back Jeremy's prior position at you.

[+CO Admin]

I don't think your explanation of Jeremy's issue will suffice in this case.

I'm sorry you feel that way. Regardless, it is my God-given right as a sycophantic blind toadie yes-man to spit back Jeremy's prior position at you.

You got a promotion Lep??? Congrats!!!!!!!!!!!!!!

[+The Leprechauns]

Yes, the addition of "sycophant" was a fairly recent development. While I'm honored by and proud of the distinction, I am a rather shy person and I did not wish to call special attention to it.

[+Cache Viking]

Yes, the addition of "sycophant" was a fairly recent development. While I'm honored by and proud of the distinction, I am a rather shy person and I did not wish to call special attention to it.

I think we need a Signal that bows before "sycophantic blind toadie yes-man"

[+The Jester]

There are any number of prior threads where Jeremy explains the logic behind "bad habits." If I'm recalling his posts correctly, it has to do with the reliance upon stale offline data as opposed to always checking the source -- Geocaching.com -- for current data.

 

I do not use GSAK. I use Watcher, and I simply download a new query or two before each geocaching trip. It works for me, and my data is always current. Not everyone feels the need to construct vast offline copies of the cache database.

Could you provide some links to these threads please? My search skills must be lacking as the only post I can find about bad habits is in this thread. I would like to understand what he meant, as it doesn't seem to make any sense to me. Thanks.

[+Hemlock]

This thread from a couple months ago has several posts from Jeremy that show his position.

[+TotemLake]

I'm mostly a cacher of opportunity. I don't have a problem with getting my PQs on a weekly basis. I"m currently having to endure a click through solution because some yahoos complain they're not gaining theirs on a daily basis. I can grudgingly deal with that because I can see the logic of the solution.

 

I pull PQs of a regional area, Washington. Using PQs in GSAK allows me to manipulate data and parse it out into smaller chunks to my PDA so it doesn't choke. That means I have different regions loaded into my PDA and I can load each depending upon where I might find myself. I routinely update those regional files.

 

Here's the problem.

 

I may not find myself in an area with adequate network or cellular signal. And even IF I did, if it isn't free, I'm unwilling to pay the extra costs for it unless I have a business need first. So checking for current data on specific caches can be out of the question if not time consuming to the point the lunch hour is eaten up making sure I'm not chasing an archived cache. This solution now becomes an engineer's answer and doesn't lead to a reasonable resolution for the customer.

 

Forget the fact my data is stale by at least a week if you're looking to fix this Daily PQ problem. I depend upon that regional data loaded in my PDA. It's as current as I need it to be and it is with me for the moment of opportunity. DNFs aren't that big of a deal, but it is if the cache is archived. My search time has been wasted because a good way to upload that archival data to my PDA is lacking because you want me to go in and manually go through all of the pages of caches to find which ones have been archived. (Bleh and yuck)

 

IMHO that's not a user friendly way to use a database resource and is too time consuming to be a realistic solution in this day and age of database queries. I have to ask myself what good is a PQ if you can't gain a simple piece of information such as a cache becoming archived? A solution is more than needed, it is justifiably required.

 

So, I went looking and noticed the Member's Premium feature now includes Insta-notify which will allow the notification of Archived caches. I have a request for two features to be added which I think would resolve this issue and add notable value to being a member.

 

Have a GPX attached to that Insta-notify message that would include the flag of those archived caches.

 

Make the Insta-notify message work with regional data. That is, with the PQs I can select Washington State as the region of interest. I would like to be able to do the same thing here instead of creating a radius from a central point to overlap areas I'm truly not interested in.

[+Team DEMP]

I'm still missing the "bad habit" reasoning.

 

I never went after a cache that was archived and though I'm not in the thousands of finds club, I do have over 500. It takes 2 seconds in GSAK to identify which caches might have been archived. My data isn't ever stale or I should say any more stale then using a PQ could possibly could be.

 

I don't over burden the PQ generator and I get 1 per day, and that's assuming there's new caches within the last week for a bunch of those days.

 

On the weekends, I get a Not Found PQ sent to me. I then create a few caching scenarios I'll go after the next day based on how I feel, who else might decide to go caching, etc. I certainly couldn't be anywhere near as prepared if I used the site live as my tool as it's no where near as efficient as GSAK.

 

Now lets forget GSAK as a tool. It might be the most popular but it's no different then any tool you'd load a PQ into. If Jeremy was so against GSAK he must be against a PQ since, if I understood his other thread, I'd just download the 2 or 3 GPX files from the cache pages and use those. So, why PQs at all then?

 

I can look at this from a revenue/cost perspective and try to guess at what is bothering Jeremy, but I don't think it's fair at all for him to take a shot at a tool a lot of us use and not explain himself. I don't think it's appropriate for everyone else to jump to Jeremy's defense and offer up why they think he made the comments he made. If he made that harsh comment because it's just not the way he does it, well that would just be silly, so there must be something more substantial then that.

[CoyoteRed]

There are any number of prior threads where Jeremy explains the logic behind "bad habits." If I'm recalling his posts correctly, it has to do with the reliance upon stale offline data as opposed to always checking the source -- Geocaching.com -- for current data.

Jeremy's logic is flawed.

 

The reason the data is stale is because he is not giving us everything we need to keep the data fresh. Our data can be as fresh as any PQ you run if we had the full information.

 

Jeremy is pointing to a symptom he created and blaming it on something else.

 

A simple file with the waypoints of all of the archived caches is all that is needed for the system to work. Not elegant, but workable. Out of curiousity I created a file with one waypoint per line and 300K lines; it was less than 3megs uncompressed. Considering gc.com doesn't even have 300K caches in existance this number is, oh, just a bit high. Additionally, as I pointed out eslewhere, you could have two files; one with all archived caches and those archived in the past month. GSAK and other off-line databases could be kept up to date with fresh data at all times. Problem solved.

[+beejay&esskay]

Since everyone else is trying to read Jeremy's mind, let me play too...

 

His problem is that since people use GSAK, they are asking for some additional programming from him.

 

If no one had an offline data base, no one "should" need to know what caches have been archived.

 

But if people use an offline data base (like GSAK), they ask for additional programming.

 

And he's busy with other stuff.

[CoyoteRed]

And he's busy with other stuff.

Yeah, like making sure everyone gets their queries. We've been discussing ways to fix that.

[+caderoux]

If no one had an offline data base, no one "should" need to know what caches have been archived.

_Everyone_ has offline databases, whether on paper, in their GPSrs, in their heads, in their computers, or in GSAK.

 

Some throw them away all the time, and some add and update them.

[+The Jester]

This thread from a couple months ago has several posts from Jeremy that show his position.

I read that when it happened, and just re-read it. It still doesn't explain "bad habits". It explained he doesn't want us to use 'stale data' - which includes PQ's. Is it a bad habit to keep a full record of the logs (which GPX files don't have) so any hints/help mentioned are available to us in the field? How can we help not using 'stale data' until the entire world has high speed wireless coverage (and we all have GPSr's that can stay connected to GC.com)?

 

Also, why did he specify GSAK, wouldn't any program that uses PQ/GPX data 'cause bad habits'? If so, why does he provide such a temptation?

[+beejay&esskay]

Also, why did he specify GSAK, wouldn't any program that uses PQ/GPX data 'cause bad habits'? If so, why does he provide such a temptation?

Jeremy was responding to someone who was using GSAK to download the PQ e-mail and that person was commenting that he would not see the information about PQs being automatically disabled after running.

 

Maybe the bad habit is not reading our e-mail.

[+Team DEMP]

Jeremy was responding to someone who was using GSAK to download the PQ e-mail and that person was commenting that he would not see the information about PQs being automatically disabled after running.

 

Maybe the bad habit is not reading our e-mail.

I don't use GSAK to read the PQ emails and I didn't notice the message in the email because I don't read the email and I just open the ZIP file. I was only made aware of this by a posting from a fellow PQ recipient. The communication about this change should have been sent out as a separate email to anyone that has a PQ scheduled with a subject that would have received some attention.

 

And I don't think you can honestly interpret

Yes. GSAK is not a good solution. It gives you bad habits.

as a reference to not reading an email. Edited August 15, 2005 by Team DEMP

[+sbell111]

Are you people really that upset because of Jeremy's flip comment? Why? When I read it, I laughed and guessed that he forgot a smilie, again. Certainly, people can find more important things to get all bendy about.

[+beejay&esskay]

Are you people really that upset because of Jeremy's flip comment? Why? When I read it, I laughed and guessed that he forgot a smilie, again. Certainly, people can find more important things to get all bendy about.

I laughed too.

 

But I can't think of anything else this morning to get bendy about.

[+Team DEMP]

Are you people really that upset because of Jeremy's flip comment?  Why?  When I read it, I laughed and guessed that he forgot a smilie, again.  Certainly, people can find more important things to get all bendy about.

Upset, as you posted, isn't the right feeling. First, I really thought I read it wrong. After I re-read it, I wasn't upset but felt that I don't think someone in his position could have made a less appropriate remark. So more then anything, my follow-up comments here are trying to understand from Jeremy (though everyone else and their brother seems to feel *they* know why Jeremy said it) what was the thought process (and here I'm giving him the benefit of the doubt he actually thought before he posted) on why he said what he said.

 

There are 3 things I need (well besides my legs) to help me best experience the hobby of geocaching. Those 3 things are:

1) Geocaching.com in providing the list of caches ($30 per year)

2) GSAK for allowing me to determine where to go and be prepared when I get there ($20 one time charge) and GPSBabel which I've been meaning to send Robert some $$ on and I'll do that right now.

3) My GPS which is currently a Garmin 76CS to get me to the cache (approx cost I can't even remember now)

 

#3 is a given. #1 is what got me interested in geocaching. #2 is what I attribute to being a better geocacher and optimizing by geocaching experience. Sure, you can find thousands of caches without #2 and even #3, but I could walk to work every day instead of drive there quicker but it doesn't mean it's the best way to acheive your goal.

 

So if everyone stops hypothesizing on why Jeremy doesn't like GSAK, maybe we can find out from him what the reason is. If not, I'll just chalk this one up to a dumb comment that was better left unposted. Until Jeremy posts again, I'll sit on the sidelines (famous last words!!).

Edited August 15, 2005 by Team DEMP

[+The Leprechauns]

Also, why did he specify GSAK, wouldn't any program that uses PQ/GPX data 'cause bad habits'? If so, why does he provide such a temptation?

I use Watcher, which is the only software performing a similar function to GSAK's "database", to my knowledge. Watcher's design encourages the user to just load in the freshest PQ. Since it does not aggregate the old logs, there's little incentive to save stale data. The only GPX file I have with stale data is the master record of the caches I've found, including archived caches. Everything else, I just load a PQ file that's a day or two old. It has just the last five logs in it. Somehow I've managed to find a few geocaches using this method.

[+sbell111]

... I don't think someone in his position could have made a less appropriate remark. ...

Hmmm. I can think of many less appropriate remarks. I think that it is a credit to this forum that inappropraite remarks are few and far between.

 

BTW, Jeremy clearly expressed his personal opinion. Is he somehow less allowed to have an opinion than you or I?

[+Hemlock]

I was just thinking. (ouch that hurts )

 

It seems that the primary reason for people I talk to, use GSAK for of having all (most?) of the logs instead of just the last 5. A secondary reason is the ability to combine several queries for a region, to hold more than the default 500 (which doesn't go far in high density areas).

 

And the biggest complaint is that archived caches are not removed easily. And let's not forget FOUND caches. They also need to be removed, but that is doable, albeit with another step.

 

It seems to me this can all be accomplished easily by simply setting a filter to only return caches that have been updated today (or whenever your last PQ was). This way your master DB will keep all the caches, including all those logs you seem so interested in keeping. But then when you export to your GPS and/or PDA, you'll only get the caches that are current and active. Archived caches will automatically be excluded by the filter.

 

Isn't that easy?

[+Team DEMP]

And the biggest complaint is that archived caches are not removed easily. And let's not forget FOUND caches. They also need to be removed, but that is doable, albeit with another step.

 

It seems to me this can all be accomplished easily by simply setting a filter to only return caches that have been updated today (or whenever your last PQ was). This way your master DB will keep all the caches, including all those logs you seem so interested in keeping. But then when you export to your GPS and/or PDA, you'll only get the caches that are current and active. Archived caches will automatically be excluded by the filter.

 

Isn't that easy?

I don't think it's a big issue to find archived caches in GSAK. Any cache which hasn't been updated within the past few days is likely disabled. It's simple at least with my subset of data to find them all within 1 click of a saved filter. The only exceptions might be ones on the very fring of a 500 cache area since sometimes they move "out" as newer caches move in so they aren't updated.

 

---------

 

As for the primary/secondary reasons you listed, I feel my primary reasons for using GSAK is automation (exporting to MapSource & a GPX for my PDA) and to very quickly find groups of caches to go out and hike and find. I'm not normally a dash & cache kind of person so finding clusters of caches is so much easier with GSAK then online. If I had to give up GSAK and go back to using the web to do this, I'd spend so much more time doing the same thing I can do now quickly.

 

Add in the instability (albeit the recent times I've been on have been more responsive) of the web site at times and it could actually prevent me from going caching.

[+Recdiver]

I use GSAK and like it. I like it a lot. I run PQs and have them e-mailed to me. Then download to my desktop so that I can run them using GSAK. For me it's just a click here, and a drag & drop there and it's done and I get to read any notes in the e-mail. A separate e-mail to me seems like a waste.

YMMV

[+TotemLake]

I use GSAK and like it.  I like it a lot.  I run PQs and have them e-mailed to me.  Then download to my desktop so that I can run them using GSAK.  For me it's just a click here, and a drag & drop there and it's done and I get to read any notes in the e-mail.  A separate e-mail to me seems like a waste.

YMMV

Maybe, but it is a different kind of database query. Having worked with databases before, I've learned the more options you add into a single database, the more likely you'll get a bad answer.

 

The Insta-notify has that Archived option built in whereas the current PQ page does not and I can see why. It's a one time notification of a specific published note on a cache that will likely not be repeated again. It isn't so important to know what the past archived caches are, but to know what current caches are being archived. That's the general complaint I keep reading here and in other threads. It satisfies the (and I stress this) current need.

 

Now correcty me if I'm wrong, but doesn't GSAK allow for exporting your notes and corrected coordinates? So if you're inclined to rebuild your database to exclude those currently archived caches, Export the notes and then import them back in to the new database. Export a GPX of the known Archived if you are keen to keeping those records. Then, coupled with the Insta-notification, you can stay current. It's not pretty, but it is doable.

Edited August 15, 2005 by TotemLake

[+TotemLake]

It seems to me this can all be accomplished easily by simply setting a filter to only return caches that have been updated today (or whenever your last PQ was). This way your master DB will keep all the caches, including all those logs you seem so interested in keeping. But then when you export to your GPS and/or PDA, you'll only get the caches that are current and active. Archived caches will automatically be excluded by the filter.

 

Isn't that easy?

No, because the workaround merely bandaids the problem, it doesn't fix it. That solution doesn't set a flag that the cache is archived. It just merely indicates it isn't currently active which isn't untrue, but it isn't entirely true either. The weakness in this workaround is exposed when you have folks out there that will log it as a find just because they were in the general area.

[+sbell111]

What was this thread about?

[+Tharagleb]

Has anyone else had problems with the pocket queries running?

 

I have 3 queries which run each day to show caches in my local area. They haven't ran in the last 4 days.

 

Is there a problem? Or am I not getting what I paid for?

This is what the thread is about. PQs not running on a timely basis.