Instead of cluttering up an already full thread, I figure it's best to start a fresh mess... Continuing from:

http://gossamer-threads.com/p/104671

I don't fully understand how values are being passed within the program (that should be obvious), but here are a couple of things I've noticed.

If I search my db for "mileage," I get two results in the Short display. Clicking directly on either one or using the prev/next links from within the Long display for either will successfully update the counter. These links would take the form of:

http://run-down.com/...records=View+Records

http://run-down.com/...ds&mh=1&nh=2

I have a feeling that's going to stretch off the screen...

It appears mh and nh are reset based on the number of results in the "query." The first link has maxhits set to 15, and there is no nh (next hit) option from the main results list. The second link is the long display (maxhits=1) and the second of 2 results (next hit=2). That much I understand.

One thing that confuses me is how that actually works? In sub html_record_long, the line that opens up the appropriate counter file is:

$count_up= "$counter_dir/$rec{$db_key}";

where $db_key = 'ID';

If there is no ID string on the search results links, how does it know the value? Does it go backtrack to find what ID corresponds to the search result query string? It obviously does work, I'm just curious why so as to better understand the part that doesn't work.

Which brings us to... the part that doesn't work! The following

http://run-down.com/...*&nh=14&mh=1

which is a Long record display after a List All query (record 14 in a single result display), does not update the couter. Other than the search field values, the only differences appear to be the presence of ID=* (which I would have thought the working examples would need in some manner to work) and view_records=1 vs. view_records=View+Records.

Still, I don't see how that's affecting whether or not the count is updated... Any ideas?

Thanks,
Dan

Also, the link from the top 10 page does not update the count:

<a href="$db_script_link_url&$db_key=$rec{$db_key}&view_records=1&ww=1">$rec{'Question'}</a>

It may be coincidental, but it appears anything with $db_key in it does not trigger the count update. That seems rather counter-intuitive to the line mentioned previously ( $count_up= "$counter_dir/$rec{$db_key}"; )...

Dan

Ok, let me rephrase the question. Using the Short/Long Display mod, the count is updated in sub html_record_long. Any record that is displayed is done so through sub html_record_long, and $db_key is the identifying field for any given record, correct? All of the other $rec{'fieldname'} values are passed through to sub html_record_long successfully, regardless of the query string, so how is it possible that $rec{'$db_key'} is not being defined?

I can't figure out what else the record is being identified by, if not by ID. Has anyone else seen this behavior and/or gotten it working correctly?

Dan

Hi Dan, I'm not quite sure what you're describing as a problem. Sorry, I'm somewhat of a newbie :-}

I've successfully used the short/long mod and I'll try to troubleshoot with you if you could help me in understanding the problem. The only thing I can question with what you have posted is $rec{'$db_key'} You indicate you're using this to call the record in the long display. Try changing that to $rec{'$ID'}

Karen

Hi Karen,

Thanks for the reply. I've tried replacing it with $rec{'ID'} (I assume that's what you meant, not $rec{'$ID'}?), but it didn't appear to make any difference.

I'll see if I can explain it clearly...

The counter in sub html_record_long works, but only when the record is viewed resulting from a search or a next/prev thereafter. If the record is viewed resulting from a "List All," category browsing (with a Category Select List on the search page), or from the Top 10 page, the counter does not work.

In each of these cases, $db_key does not appear to have any value in sub html_record_long. The only pattern I can as to why it does not hold a value is that ID (which is what $db_key is) is passed to the sub in some fashion in those instances.

This seems completely backward. It would make sense that ID would have a value only when a value is passed to it, but it seems to be just the opposite. The search results do not have ID in the string that is passed, just mh and nh values along with the search terms, yet they are able to interpret the ID and update the counter...

Does that make more sense? If there is a particular part that is confusing, I can try explaining that piece in more detail.

Again, the db in question is at:

http://run-down.com/...lt&view_search=1

Thanks,
Dan

Hi Dan, okay, I believe I know what you're describing. I'll take a look at the count mod to see if I can spot anything which is limiting the output to just certain calls. It seems that is where the actual problem stems from since the count is incrementing on some but not others.

Agreed. I just can't help but think there is something odd about which $rec values are functioning and which (ID) aren't. It seems there is a larger issue than just the counter mod, but maybe it's the only thing dependent enough on the ID in that particular place to be affected?

As you can see from the link, the db is set up for default users. It also has the Category Search added in, but most everything else is standard.

Thanks,
Dan

Dan, I'm curious whether the count is intended to increase based only on the short record display to prevent the counter from incrementing once on the short display (a search result or Top 10 display, etc) and then again when the long record is viewed.

These darn wwwthreads reply-to-post (as opposed to original poster) never give you reply notifcation when you're expecting it...

The instructions in the Top Ten mod say:


# In sub html_record (or sub html_record_long, if you're using the
# short/long display mod), after

my (%rec) = @_;

# add

$count_up= "$counter_dir/$rec{$db_key}";
open (COUNT, "<$count_up");
$countup = <COUNT>;
close COUNT;
open (COUNT, ">$count_up");
$countup2 = $countup 1;
print COUNT $countup2;
close COUNT;


Which is what makes the most sense to me. If you put it in the short record display, you would probably be counting all search/list results, not just the one(s) actually viewed.

Dan

I'm still struggling to make some sense of this. One correction from what I said above is that the counter does indeed work when viewing a record as a result of browsing a category. I guess this is the same as a search, so that makes sense.

With a List All, it seems the ID=* is a cause of some trouble. I can't figure out how the other fields for each record backtrack to an ID number in the database, but ID itself certainly doesn't seem to be able to. Of course, that doesn't explain why the counter doesn't update as a result of clicking through from the Top 10 page, which contains a value for ID in the link...

Dan

Problem solved:

http://gossamer-threads.com/...w=collapsed&sb=5

Whew! Turned out to be very simple.

Dan