FW: Any concerns with using NUL char with PowerHouse
John MacLerran
macljohn@isu.edu
Fri, 18 Jan 2002 12:36:59 -0700
Hi PH Listers,
I'll step in here for a moment and try to explain what we're trying to do.
One thing Richard didn't mention is that we're using PHWeb to allow users to enter
data into a legacy system. The legacy system has a description dataset that stores
multiple 60-byte lines to make up a larger description. Quick deals very well with
that layout in a cluster, but on the web form, we want to allow the users to enter
data into a freeform text box and then we want to programmatically break it apart
into the 60 byte lengths that Image needs.
If we break it at exactly 60 bytes (e.g. def xyz char*60 = LONG-FIELD[1:60]), then
we end up breaking words across the 60 byte boundary and when we present the
description back to the user in the free-form web box, the text looks wierd because
some wo rds en d up wit h spaces i n th e wrong pl ace. If we break at exactly 60
bytes, and, on redisplay remove any space at the end of the line, then we get some
cases where twowords are puttogether without the originalspaces that were there.
As Marvin the Martian would say: Annoying, isn't it?
SO, we developed an algorithm that can, somewhat intelligently, break the long
description into 60-byte lengths and not break words -- that algorithm looks for
spaces within the text and attempts to divide the description at the nearest
natural break. This works great for straight english text, but chokes when a user
types in more than 60-bytes without a space -- something very common if the user
is, for example, typing in a long URL (the system is a purchasing system, and the
user might want to reference a URL from, say, DELL's configuration page, which is
often longer than 60 bytes). In this case, the description might say: I want a PC
with the configuration as shown at this site:
http://configure.us.dell.com/dellstore/config.asp?customer_id=04&keycode=6W463&order_code=dim8222i
Since there is no space in the URL, the algorithm basically ignores it and drops it
from the data. What Richard is trying to do is to modify the algorithm such that
when it finds a portion of the long description that is more than 60 bytes without
a space, insert a <nonprinting, not a space, 'ghost' character of some sort> at 59
bytes, and break the string there arbitrarily. Then, when re-assembling the 60-byte
chunks for redisplay, he can remove the <'ghost character'>, conantenate the rest
of the string at that point and redisplay the long field. This fixes the wierd
display problems and preserves the URL encoding. Also, as a side benefit, the fact
that it doesn't mess up quiz and printing is helpful, because all of the system
reports deal perfectly with the 60-byte field as is, and I don't want to have to
assign Richard the task of redesigning the database and all the reports to deal
with a larger field :-). Plus, we don't want to change the description to be a
single 600-byte field because we have lots of Purchased items that read: I need 5
cans of blue paint. In Image, that adds up to a lot of wasted disc space.
I hope that clarifies things. From what we've heard so far, Image doesn't care if
we define a character of all binary zeros -- it's not a key field, so we're ok
there. We don't use Query, so we're not concerned with display problems there, and
Quiz (and slaved printing) seems to ignore it, so that's good too. We'll probably
use a defined binary-zero character as our ghost character.
Darren Reely wrote:
> Blue,
>
> Richard isn't talking NULL. He is talking about ascii value zero, NUL.
> Being an ascii character, it should take up space in a database if the
> database doesn't object. Surprisingly, quiz prints an empty string for it,
> and it can be used in concatenation without the side effect of creating a
> NULL string.
>
> I'm still trying to understand what he really wants to do with it.
>
> ;On Sun Solaris
> define my_nul_num INT*3 UNS SIZE 1 = 0
> define my_nul CHAR*1 = CHAR(my_nul_num)
> define my_NULL char*1 = NULL
> define result_is_null char*20 = 'mystring' + my_NULL
> define result_is_mystring char*20 = 'my' + my_nul + 'string'
>
> Darren
>
> "Edis, Bob" wrote:
> >
> > G'day Richard
> >
> > I've had problems in the past where an index used from primary file
> > retrieval in a screen contained a null. The results were unpredictable but
> > often records could not be viewed even though a user had just entered them.
> > These were NOT the records that contained the NULL. Removing the NULLs from
> > the index column eliminated the problem.
> >
> > Regards,
> > Blue
> >
> > -----Original Message-----
> > From: Richard Sheehan [mailto:sheerich@isu.edu]
> > Sent: Thursday, January 17, 2002 5:01 PM
> > To: PowerHouse List
> > Subject: Any concerns with using NUL char with PowerHouse
> >
> > Hello,
> >
> > Does anyone know of any undesirable side effects of storing the acsii(0)
> > NUL in a field in an Image Dataset? And for the ?inevitable? future,
> > how about any other DB's for that matter?
> >
> > How might this affect any PowerHouse applications?
> >
> > Initial testing seems to show no side effects. Size() and Index() seem
> > to work properly on the test data. Printing also seems unaffected.
> >
> > I'm looking to use it or another ascii character as a logical separator
> > in free form text entry, when no space occurs in the text, such as in a
> > URL string.
> >
> > TIA,
> >
> > --
> > Richard Sheehan,
> > Administrative Systems - IT Programmer Analyst
> > Idaho State University Computing & Communications
> > Campus Box 8037, Pocatello, ID 83209-8037
> > Phone: 208.282.3861 - Fax: 208.282.3673
> > Email: sheerich@isu.edu
> >
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > Mailing list: powerh-l@lists.swau.edu
> > Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> > Unsubscribe: "unsubscribe" in message body to
> > powerh-l-request@lists.swau.edu
> > http://lists.swau.edu/mailman/listinfo/powerh-l
> > This list is closed, thus to post to the list you must be a subscriber.
> >
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > Mailing list: powerh-l@lists.swau.edu
> > Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> > Unsubscribe: "unsubscribe" in message body to powerh-l-request@lists.swau.edu
> > http://lists.swau.edu/mailman/listinfo/powerh-l
> > This list is closed, thus to post to the list you must be a subscriber.
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.
--
----------------------------------------------------------------------
John MacLerran
IT Systems Analyst email: macljohn@isu.edu
Idaho State University V(208) 282-2954
http://www.isu.edu/~macljohn F(208) 282-3673
----------------------------------------------------------------------