Re: I find this type=num search strange
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 48983
interpreted = N
texte = No answers for ya, but this type of info sure would be good to have postedto the new online docs for future reference :)http://webdna.smithmicro.com/ref/index.htmlGK-----Original Message-----From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf OfMatthew A PerosiSent: Thursday, March 27, 2003 5:04 PMTo: WebDNA TalkSubject: I find this type=num search strangeThis is not a question, rather a posting of something I spent 2 hours ontoday.I thought the list would find it interesting. I'm using RedHat 7.2 with4.5.1I'm working on a project here and I was thinking to have a database recordwith a SKU of Zero (0). In 4 years I never before thought of using SKU 0,butI have my crazy reasons this time.To my surprise, when using a search such as the following:[search db=admins.db&SKUsort=1&SKUtype=num&SKUsdir=as&neSKUdata=find_all]I am returned with all my records in the correctly sorted order EXCEPT sku0.I did some digging in the archives and found out that when using type=numyou needto be careful that your comparison data is actually a numerical valueotherwise thatcomparison data will be replaced with a null value.In other words:when type=numneSKUdata=find_allis converted to:neSKUdata=I tested this several times and several different ways. I did find that youcoulduse:neSKUdata=999999999and it would result in returning all my records in the correctly sortedorderINCLUDING sku 0.Why would WebDNA so obviously not include zero when doing a find_allsearch?Since we all assume that the common neSKUdata=find_all search actuallyreturns allof our records. Perhaps SMI could change that find_all variable that isso oftenused in the WebMerchant with the variable find_all_but_zero. I testedthis evenfurther on other web sites I have created by adding SKU 0 products and Iended upwith very bizarre results since none of my sites to date know how to handlea SKU 0record.I'd invite comments on this one. My curiosity is peeked if any guys haveeverbumped into this issue. Did SMI totally overlook this?For me this turned out to be more of a feature than a bug. I was actuallylookingfor a way to create a hidden record. It's strange that I found a built inhiddenrecord so quickly! :-)Matthew A PerosiPsi Prime, Inc.nj-singles.comijo.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://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
No answers for ya, but this type of info sure would be good to have postedto the new online docs for future reference :)http://webdna.smithmicro.com/ref/index.htmlGK-----Original Message-----From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf OfMatthew A PerosiSent: Thursday, March 27, 2003 5:04 PMTo: WebDNA TalkSubject: I find this type=num search strangeThis is not a question, rather a posting of something I spent 2 hours ontoday.I thought the list would find it interesting. I'm using RedHat 7.2 with4.5.1I'm working on a project here and I was thinking to have a database recordwith a SKU of Zero (0). In 4 years I never before thought of using SKU 0,butI have my crazy reasons this time.To my surprise, when using a search such as the following:[search db=admins.db&SKUsort=1&SKUtype=num&SKUsdir=as&neSKUdata=find_all]I am returned with all my records in the correctly sorted order EXCEPT sku0.I did some digging in the archives and found out that when using type=numyou needto be careful that your comparison data is actually a numerical valueotherwise thatcomparison data will be replaced with a null value.In other words:when type=numneSKUdata=find_allis converted to:neSKUdata=I tested this several times and several different ways. I did find that youcoulduse:neSKUdata=999999999and it would result in returning all my records in the correctly sortedorderINCLUDING sku 0.Why would WebDNA so obviously not include zero when doing a find_allsearch?Since we all assume that the common neSKUdata=find_all search actuallyreturns allof our records. Perhaps SMI could change that find_all variable that isso oftenused in the WebMerchant with the variable find_all_but_zero. I testedthis evenfurther on other web sites I have created by adding SKU 0 products and Iended upwith very bizarre results since none of my sites to date know how to handlea SKU 0record.I'd invite comments on this one. My curiosity is peeked if any guys haveeverbumped into this issue. Did SMI totally overlook this?For me this turned out to be more of a feature than a bug. I was actuallylookingfor a way to create a hidden record. It's strange that I found a built inhiddenrecord so quickly! :-)Matthew A PerosiPsi Prime, Inc.nj-singles.comijo.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://webdna.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:
Beta Documentation (1997)
price on detail, but not shoppingcart (1997)
Trouble with Netscape (1998)
Appending current [date] to a database (1997)
WC2b15 File Corruption (1997)
Setting up shop (1997)
PIXO support (1997)
'RequiredField' Question (1998)
restart needed???? (1997)
problem with dates, NT version (1997)
[index] (1997)
[WebDNA] MailChimp (2012)
[WebDNA] 301 redirect (2016)
Large founditems loops (2000)
WC2f3 (1997)
numfound question (2005)
WebCat2b13MacPlugIn - [showif][search][/showif] (1997)
Searching (second post) (1999)
Country & Ship-to address & other fields ? (1997)
Core Database integration (2001)