Hopefully this is an easy one - usually we use "normal" characters to
divide/separate id's or attributes, i.e.

123*456

Splitting this into 2 fields is easy with G0*1 or G1*1 in the correlative.
If I wanted to use something like CHAR(0) instead of an asterisk, what would
the correlative look like? Tried a few different ways, can't seem to get it
to work.

Thanks again in advance.

Scott Deardorff

Scott Deardorff wrote:
*Don't do that*. I will cause you great pain. Just
because something can be done does not mean it should.

Patrick, <;=)

P.S. Your DB and OS may be pertinent information.

If you feel that you MUST use a char(0) or some other
unprintable/unenterable character, then I would think that a call would
be your easiest/most obvious solution.

If you wanted to be "devious" you could actually do a translate to
another file (with a key of, say, "char(0)" so it was more obviousto
obtain a seperator, then do the group extract using the result, but I
hate nasty F-correlatives (in public), so I'll just keep with the CALL
dict item (does work - just tried it)


Scott Deardorff wrote:

latimerp wrote:

Using non-printable characters is simply a bad idea. It's probably
good that creating a correlative for such a thing is difficult in a
dict item.

Obviously in BASIC this isn't tough, though it's still "mostly
unadvised":

info = first:char(0):second
first1 = field(info,char(0),1)
second1 = oconv(info,"g1":char(0):"1")

That sort of thing really is OK if you're creating and parsing data
transmissions for a remote host. Outside of that there is no good
business case for using a non-printable char, and never as an ID. If
your data is so diverse that you think it's possible for an ID to be
created by a user with ambiguous delimiters, then you're not using the
right key structure. Example:
- User #123 enters "!@#$%^&*()~|\][}{-=+" as data for client 456.
- You then store it as ID 123*!@#$%^&*()~|\][}{-=+*456
If you're looking to char(0) to avoid that problem, that's not the
problem on which you should be focusing. And if you need to
query that data, then again, you should reconsider how it's
structured, and use industry-standard delimiters.

T



"Scott Deardorff" wrote:

Let me clarify. This is for a temporary work file only. This temporary ID
will be made up of several pieces of data, all of which could possibly
contain most of the printable characters. I need a separation character
that could NOT possibly be entered by a user. The application already has
speed issues parsing through a ton of data, so I was trying to avoid using
CALLs if possible.

"Scott Deardorff" <smdamd (AT) bellsouth (DOT) net> wrote

Ok Scott - no characters on the keyboard.
Then put in your Char(0) or char(127) or something exotic in the keys.
Then use a hex editor to build the "g" extract codes.
http://www.ultraedit.com/
Tom


"Scott Deardorff" <smdamd (AT) bellsouth (DOT) net> wrote

On Jan 19, 5:53 am, "Scott Deardorff" <smd... (AT) bellsouth (DOT) net> wrote:
Hi Scott -- as mentioned above you do not mention your DB - If you are
on u2 then you can place CHAR(0) in an I correlative.

Rgds
Symeon.

Delving into the request shows a perfectly valid reason for it.

If you're using RD with their limited ability to manage issues, you may want
to check if char(0) is valid...vide recent post where : was not acceptable
for NT D3. So if you don't want a response on this list that says "what do
you expect *that* to do?", check it out first. Btw, I sometimes use
char(160) which displays as blank, thus giving some indication to the user
that there's a character there.

That said, Scott, on "real" terminals you can use control-some weird keys to
create char(0) and various other funnies. Not sure about emulators. But with
most, you can soft change some key temporarily.

If nothing else, write a 3 line BASIC program to convert the G0~1 to
G0[char(0)]1 in the Dicts you need.

Chandru

"Scott Deardorff" <smdamd (AT) bellsouth (DOT) net> wrote

Why use a compound key at all? In D3 you can use system(19) [guaranteed
unique date+time+alpha], or how about just a sequential numeric key
(hashes best) fed from a single source?

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Scott Deardorff wrote: