Re: [WebDNA] [replacefounditems] fails
This WebDNA talk-list message is from 2009
It keeps the original formatting.
numero = 104144
interpreted = N
texte = It was plain text data and the values were URLed which should have dealt with any unusual characters anyways. Sincerely, Kenneth Grome www.KenGrome.com > I've never had an issue with replacefounditems and have used it for quite sometime. I would look at the data you were putting into the fields its possible that some special characters caused the failures. The world will never know. > > On Dec 10, 2009, at 12:37 AM, Kenneth Grome wrote: > > > It's too late to post the code that fails because I already replaced it with code that works, and I'm not spending any more time on this anyways, I only posted my last message here so that if someone else sees replacefounditems failing in an unusual manner they will have a head's up as to why, or if they want to avoid getting into the same situation I did they can just avoid using replacefounditems altogether. > > > > Sincerely, > > Kenneth Grome > > www.KenGrome.com > > > > > > > > > > > > > > > >> Ken, you know the drill ;-), > >> > >> Post your exact code (with sample values) > >> Also, post your specs... > >> > >> D > >> > >> =================== > >> d.brooke - mobile > >> www.euca.us > >> =================== > >> > >> On Dec 9, 2009, at 11:52 PM, Kenneth Grome
wrote: > >> > >>> I think there's some kind of bug in replacefounditems, I couldn't > >>> get it to replace both of the values I was trying to replace, it > >>> would only replace one -- the same one each time -- even when I > >>> switched their positions inside the replacefounditems context. > >>> > >>> At first I thought it might be a problem with their positions, > >>> that's why I switched them, but it didn't matter because only one > >>> would get replaced and the other was ignored consistently. Then I > >>> thought it might be a db format issue but that wasn't it either. > >>> > >>> Then I thought that because one of the field names was "cookie" that > >>> might be the problem so I changed it to kookie but that still didn't > >>> help. I checked my formvariables and all the values were being > >>> passed as expected, the only problem was that the replacefounditems > >>> was only replacing one of the two values it contained. > >>> > >>> Both values were URLed and I did not try NOT URLing them so maybe > >>> that's the problem. I spent close to 2 hours on this just trying to > >>> figure out what was wrong with my code, when all the time there was > >>> nothing wrong with my code at all. It was just a screw-up in the > >>> replacefounditems context that was causing the problem -- and I'm > >>> sure of this because when I eventually decided to use a [replace] > >>> context I used the exact same parameter string inside the replace > >>> that I was using in the replacefounditems ... and both values were > >>> replaced properly the very first time I tried it. > >>> > >>> Very strange. This is the first time I've seen such behavior, but > >>> it makes me distrust using replacefounditems now. > >>> > >>> It would be interesting to hear if anyone else has seen > >>> replacefounditems fail when more than one value is being replaced, > >>> and/or if anyone has seen strange behavior like this when the values > >>> are URLed. I just don't get it, but it leaves me thinking that this > >>> may really be a bug in the software. > >>> > >>> Sincerely, > >>> Kenneth Grome > >>> www.KenGrome.com > >>> --------------------------------------------------------- > >>> This message is sent to you because you are subscribed to > >>> the mailing list . > >>> To unsubscribe, E-mail to: > >>> archives: http://mail.webdna.us/list/talk@webdna.us > >>> old archives: http://dev.webdna.us/TalkListArchive/ > >>> Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >> --------------------------------------------------------- > >> This message is sent to you because you are subscribed to > >> the mailing list . > >> To unsubscribe, E-mail to: > >> archives: http://mail.webdna.us/list/talk@webdna.us > >> old archives: http://dev.webdna.us/TalkListArchive/ > >> Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >> > > > > --------------------------------------------------------- > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > archives: http://mail.webdna.us/list/talk@webdna.us > > old archives: http://dev.webdna.us/TalkListArchive/ > > Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >
Associated Messages, from the most recent to the oldest:
It was plain text data and the values were URLed which should have dealt with any unusual characters anyways. Sincerely, Kenneth Grome www.KenGrome.com > I've never had an issue with replacefounditems and have used it for quite sometime. I would look at the data you were putting into the fields its possible that some special characters caused the failures. The world will never know. > > On Dec 10, 2009, at 12:37 AM, Kenneth Grome wrote: > > > It's too late to post the code that fails because I already replaced it with code that works, and I'm not spending any more time on this anyways, I only posted my last message here so that if someone else sees replacefounditems failing in an unusual manner they will have a head's up as to why, or if they want to avoid getting into the same situation I did they can just avoid using replacefounditems altogether. > > > > Sincerely, > > Kenneth Grome > > www.KenGrome.com > > > > > > > > > > > > > > > >> Ken, you know the drill ;-), > >> > >> Post your exact code (with sample values) > >> Also, post your specs... > >> > >> D > >> > >> =================== > >> d.brooke - mobile > >> www.euca.us > >> =================== > >> > >> On Dec 9, 2009, at 11:52 PM, Kenneth Grome wrote: > >> > >>> I think there's some kind of bug in replacefounditems, I couldn't > >>> get it to replace both of the values I was trying to replace, it > >>> would only replace one -- the same one each time -- even when I > >>> switched their positions inside the replacefounditems context. > >>> > >>> At first I thought it might be a problem with their positions, > >>> that's why I switched them, but it didn't matter because only one > >>> would get replaced and the other was ignored consistently. Then I > >>> thought it might be a db format issue but that wasn't it either. > >>> > >>> Then I thought that because one of the field names was "cookie" that > >>> might be the problem so I changed it to kookie but that still didn't > >>> help. I checked my formvariables and all the values were being > >>> passed as expected, the only problem was that the replacefounditems > >>> was only replacing one of the two values it contained. > >>> > >>> Both values were URLed and I did not try NOT URLing them so maybe > >>> that's the problem. I spent close to 2 hours on this just trying to > >>> figure out what was wrong with my code, when all the time there was > >>> nothing wrong with my code at all. It was just a screw-up in the > >>> replacefounditems context that was causing the problem -- and I'm > >>> sure of this because when I eventually decided to use a [replace] > >>> context I used the exact same parameter string inside the replace > >>> that I was using in the replacefounditems ... and both values were > >>> replaced properly the very first time I tried it. > >>> > >>> Very strange. This is the first time I've seen such behavior, but > >>> it makes me distrust using replacefounditems now. > >>> > >>> It would be interesting to hear if anyone else has seen > >>> replacefounditems fail when more than one value is being replaced, > >>> and/or if anyone has seen strange behavior like this when the values > >>> are URLed. I just don't get it, but it leaves me thinking that this > >>> may really be a bug in the software. > >>> > >>> Sincerely, > >>> Kenneth Grome > >>> www.KenGrome.com > >>> --------------------------------------------------------- > >>> This message is sent to you because you are subscribed to > >>> the mailing list . > >>> To unsubscribe, E-mail to: > >>> archives: http://mail.webdna.us/list/talk@webdna.us > >>> old archives: http://dev.webdna.us/TalkListArchive/ > >>> Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >> --------------------------------------------------------- > >> This message is sent to you because you are subscribed to > >> the mailing list . > >> To unsubscribe, E-mail to: > >> archives: http://mail.webdna.us/list/talk@webdna.us > >> old archives: http://dev.webdna.us/TalkListArchive/ > >> Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >> > > > > --------------------------------------------------------- > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > archives: http://mail.webdna.us/list/talk@webdna.us > > old archives: http://dev.webdna.us/TalkListArchive/ > > Bug Reporting: http://forum.webdna.us/eucabb.html?page=topics&category=288 > >
Kenneth Grome
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:
Problems with [Search] param - Mac Plugin b15 (1997)
Email check problems -1 (1999)
searching for items that begin with a number (2004)
WCS Newbie question (1997)
Problems with webcat 2.01 for NT (1997)
More on the email templates (1997)
case sensitivity in lookups (1997)
[OT] Am I an Idiot? (2004)
Associative lookup style? + bit more (1997)
is there a [purchase]? (1998)
possible bug in unix version? (2000)
Moment of Thanks (1997)
Comments in db? (1997)
required fields (1998)
PCS Frames (1997)
listfiles, moving files (1998)
Memory Error message (1998)
frames & carts (1997)
expired beta (1997)
Where is f2? (1997)