Re: [WebDNA] [append] does not add the newline char at the end of the new record?! (which causes subsequent [search] to fail.)
This WebDNA talk-list message is from 2009
It keeps the original formatting.
numero = 103344
interpreted = N
texte = You could add in an extra append until it gets fixed and then do a clean up after ..... Regards Stuart Tremain IDFK Web Developments AUSTRALIA webdna@idfk.com.au On 20/08/2009, at 10:57 AM, John Butler wrote: >> John Butler wrote: >>> Version=6.1 >>> PLATFORM=unix-Linux Intel RedHat >>> I have a problem that is forcing me to think of creative >>> workarounds for today's code, but more than that is disturbing in >>> general: >>> I have a perfectly normal and working [append] context.. but it >>> is not ending the record it appends with a newline char. I've >>> seen that before, but just decided to myself that it must be OK >>> (even though a faint voice said it was not supposed to be that >>> way). Once I append another record, then the previous record >>> does get it's delimiting newline char. >>> Well now I am doing a *simple* search on this db, and it finds any >>> specific one record I tell it to find, UNLESS I am trying to find >>> that last record with no newline char at the end. If I manually >>> add the newline char at the end, then the search works as expected. >>> Has anyone had any such experience? Suggestions? >> >> I'm a bit confused at what you are asking.. but >> I would definitely update your "6.1" version to "6.2". >> >> Not sure what release that is that you are using, because we >> didn't officially release a "6.1" version. >> >> Re: your append, maybe post some code?.. and maybe >> a more terse description of what is going on? >> >> Donovan > > This code: > > Version=[version] > PLATFORM=[PLATFORM] > > returns this: > Version=6.1 > PLATFORM=unix-Linux Intel RedHat > > I would LOVE to update the release, but this is on a shared host. I > will put in a request.. but the webdna man there is on honeymoon... > so it won't happen now. Meanwhile I have to produce for the client > now. > > ---------------- > > this code: > > [Append db=^dir/mydb.db]field1=123&field2=[url][val][/ > url]...&field24=none_yet[/Append] > > successfully and accurately writes to mydb.db. It writes the new > record which I just asked it to. * BUT * this new record does NOT > have a newline char at the end... UNTIL / UNLESS I [append] > another record. > > So what? Meaning, why would we care? > > I care because: I find that when I later search for that newly- > appended record with [search db=^dir/ > mydb.db&eqfield1datarq=123&max=1], then the [search] will NOT find > that record UNTIL / UNLESS I first add a newline char at the end of > the record. I can add that missing newline char either manually, by > directly editing the db, or else I have to [append] another record > so the previous one finally gets its newline char at the end. > > How'd I do? Clear? Terse? :-) > > -G > > --------------------------------------------------------- > 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:
You could add in an extra append until it gets fixed and then do a clean up after ..... Regards Stuart Tremain IDFK Web Developments AUSTRALIA webdna@idfk.com.au On 20/08/2009, at 10:57 AM, John Butler wrote: >> John Butler wrote: >>> Version=6.1 >>> PLATFORM=unix-Linux Intel RedHat >>> I have a problem that is forcing me to think of creative >>> workarounds for today's code, but more than that is disturbing in >>> general: >>> I have a perfectly normal and working [append] context.. but it >>> is not ending the record it appends with a newline char. I've >>> seen that before, but just decided to myself that it must be OK >>> (even though a faint voice said it was not supposed to be that >>> way). Once I append another record, then the previous record >>> does get it's delimiting newline char. >>> Well now I am doing a *simple* search on this db, and it finds any >>> specific one record I tell it to find, UNLESS I am trying to find >>> that last record with no newline char at the end. If I manually >>> add the newline char at the end, then the search works as expected. >>> Has anyone had any such experience? Suggestions? >> >> I'm a bit confused at what you are asking.. but >> I would definitely update your "6.1" version to "6.2". >> >> Not sure what release that is that you are using, because we >> didn't officially release a "6.1" version. >> >> Re: your append, maybe post some code?.. and maybe >> a more terse description of what is going on? >> >> Donovan > > This code: > > Version=[version] > PLATFORM=[platform] > > returns this: > Version=6.1 > PLATFORM=unix-Linux Intel RedHat > > I would LOVE to update the release, but this is on a shared host. I > will put in a request.. but the webdna man there is on honeymoon... > so it won't happen now. Meanwhile I have to produce for the client > now. > > ---------------- > > this code: > > [Append db=^dir/mydb.db]field1=123&field2=[url][val][/ > url]...&field24=none_yet[/Append] > > successfully and accurately writes to mydb.db. It writes the new > record which I just asked it to. * BUT * this new record does NOT > have a newline char at the end... UNTIL / UNLESS I [append] > another record. > > So what? Meaning, why would we care? > > I care because: I find that when I later search for that newly- > appended record with [search db=^dir/ > mydb.db&eqfield1datarq=123&max=1], then the [search] will NOT find > that record UNTIL / UNLESS I first add a newline char at the end of > the record. I can add that missing newline char either manually, by > directly editing the db, or else I have to [append] another record > so the previous one finally gets its newline char at the end. > > How'd I do? Clear? Terse? :-) > > -G > > --------------------------------------------------------- > 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
Stuart Tremain
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:
Multiple security dbs (1997)
Problems appending to database (1997)
Date Question (2002)
Emailer setup (1997)
if else problem (2003)
Problem (1997)
Can webcat 3.0/4.0 handle 1,000,000 hits a day? (2000)
[OT] Display Glitch (2004)
default error on NT? (1997)
Re:WebCat Emailer & Liststar (1997)
[WebDNA] INCLUDE file= in the footer (2009)
OK, here's a new one (2002)
[searchString] (1997)
TeaRoom Order fields email account remain empty even though thewy are filled. (1997)
Link with [cart] in db field (1999)
Hierarchy of form/text/math variables (2000)
Sort Order on a page search (1997)
japanese characters (1997)
[ShowNext] (1997)
Reversed words (1997)