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:
Possible Bug in 2.0b15.acgi (1997)
New servers and new inline cache (1997)
Why WebMerchant not working? (1999)
Search for starts with and ends with? (2003)
Secured Order Forms (1998)
Encrypt broken on Mac 3.05b13?? (2000)
[WebDNA] To be or not to be friendly (URLs) (2011)
shownext (1997)
Migrating to NT (1997)
Need relative path explanation (1997)
Emailer help....! (1997)
BUG NOTICE: (2003)
Webcatalog error, Plug-in for Webstar (1996)
searchable list archive (1997)
Help! WebCat2 bug (1997)
One other big addition... (1997)
Root Folder problems cont. (1998)
NT Manual (1997)
Problems passing [SKU] with $Replace in 2.0 (1997)
Bit off subject -- Faxing orders (1997)