Re: Odd search results, or odd programmer, not sure which...
This WebDNA talk-list message is from 2002
It keeps the original formatting.
numero = 42874
interpreted = N
texte = I know what I was going to ask, but got distracted...I'm not concerned about having to further filter the search results, I'm curious about the order of the elements that compose the search. I was unaware of there being any difference, I didn't think it mattered, but apparently it does. Based on the the search results that I was getting from my original post, depending on where each element (is there a better word?) is placed, the results are affected.Assuming again....the program is sorting records as it's conducting the search from left to right through your searchstring. So, if one element limits a certain set of records, or orders them or includes them, then the next element further refines that recordset and so on until the search is completed. Is this correct? Is there a logical order? I'm thinking I should start adjusting my searches to something like this order:1. data to include (such as neskudatarq=[blank]) 2. smaller data to exclude 3. sub-data of that to either include/exclude 4. etc... 5. sort order of outputOr am I just overthinking this? Perhaps I'm over-caffenated at this time now....GK | Thanks. I was just thinking that as well based on Glenn's post. I would be | using a [replace] as well and could filter that with the hideif's. | | On my pop-up window, I suppose I could of wrapped the output of the page in | the hideif's to not show the HE's and used a showif to just show the | _open's. | | Perhaps this shows that there are some limitations in what you can/cannot | search for without having to further filter the results with | hideif's/showif's. Would still work though. | | Thanks all for the suggestions, | GK | | | Hey Gary, | | | | I would do a search for those records that contain the 'open' and then use | a | | [hideif] of the 'if then' to remove those that contain the 'HE': | | | | [search db=some.db&woLOCATIONSdatarq=_open&LOCATIONSword=ss] | | [founditems] | | | | -- hideif -- | | [hideif [locations]^HE] | | | | -- if then -- | | [If ([locations]^HE)] | | [Else]what ever you want to do here when LOCATIONS did not contain | | HE[/Else] | | [/If] | | | | Just my thoughts. | | | ------------------------------------------------------------- | This message is sent to you because you are subscribed to | the mailing list
. | To unsubscribe, E-mail to: | To switch to the DIGEST mode, E-mail to | Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Associated Messages, from the most recent to the oldest:
| |
- Re: Odd search results, or odd programmer, not sure which... (Kenneth Grome 2002)
- Re: Odd search results, or odd programmer, not sure which... (Gary Krockover 2002)
- Re: Odd search results, or odd programmer, not sure which... (Brian Fries 2002)
- Re: Odd search results, or odd programmer, not sure which... (Gary Krockover 2002)
- Re: Odd search results, or odd programmer, not sure which... (Gary Krockover 2002)
- Re: Odd search results, or odd programmer, not sure which... (Inkblot Media 2002)
- Re: Odd search results, or odd programmer, not sure which... (Inkblot Media 2002)
- Re: Odd search results, or odd programmer, not sure which... (Gary Krockover 2002)
- Re: Odd search results, or odd programmer, not sure which... (Glenn Busbin 2002)
- Odd search results, or odd programmer, not sure which... (Gary Krockover 2002)
|
I know what I was going to ask, but got distracted...I'm not concerned about having to further filter the search results, I'm curious about the order of the elements that compose the search. I was unaware of there being any difference, I didn't think it mattered, but apparently it does. Based on the the search results that I was getting from my original post, depending on where each element (is there a better word?) is placed, the results are affected.Assuming again....the program is sorting records as it's conducting the search from left to right through your searchstring. So, if one element limits a certain set of records, or orders them or includes them, then the next element further refines that recordset and so on until the search is completed. Is this correct? Is there a logical order? I'm thinking I should start adjusting my searches to something like this order:1. data to include (such as neskudatarq=[blank]) 2. smaller data to exclude 3. sub-data of that to either include/exclude 4. etc... 5. sort order of outputOr am I just overthinking this? Perhaps I'm over-caffenated at this time now....GK | Thanks. I was just thinking that as well based on Glenn's post. I would be | using a [replace] as well and could filter that with the hideif's. | | On my pop-up window, I suppose I could of wrapped the output of the page in | the hideif's to not show the HE's and used a showif to just show the | _open's. | | Perhaps this shows that there are some limitations in what you can/cannot | search for without having to further filter the results with | hideif's/showif's. Would still work though. | | Thanks all for the suggestions, | GK | | | Hey Gary, | | | | I would do a search for those records that contain the 'open' and then use | a | | [hideif] of the 'if then' to remove those that contain the 'HE': | | | | [search db=some.db&woLOCATIONSdatarq=_open&LOCATIONSword=ss] | | [founditems] | | | | -- hideif -- | | [hideif [locations]^HE] | | | | -- if then -- | | [If ([locations]^HE)] | | [Else]what ever you want to do here when LOCATIONS did not contain | | HE[/Else] | | [/If] | | | | Just my thoughts. | | | ------------------------------------------------------------- | This message is sent to you because you are subscribed to | the mailing list . | To unsubscribe, E-mail to: | To switch to the DIGEST mode, E-mail to | Web Archive of this list is at: http://search.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/
Gary Krockover
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Re:Searching for ALL / empty form field *the FINAL answer* (1997)
4.5.0 (2002)
[WebDNA] XML parsing issue with cdata (2012)
another problem (1997)
New Plug-in and Type 11 errors (1997)
New public beta available (1997)
ShoppingCart clearing code (2004)
Reindexing a db with duplicate numbers... (1999)
WebCat2b13MacPlugIn - [showif][search][/showif] (1997)
WC1.6 to WC2 date formatting (1997)
WebCatalog not recognizing ShoppingCarts folder (2000)
Rendering out a page (1997)
Loops and [index] (1998)
View Source from cache (1997)
Forbidden CGI Error (1997)
Help name our technology! (1997)
why is this line in GeneralStore? (1998)
Huge databases and RAM (1998)
WebDNA Server Not Running (2005)
Email (1998)