[vox-tech] Changing data with awk

[Matthew Lange]

Actually, replacing the data in SQL Server is quite easy.  You need to
search for the ASCII value, and then use the REPLACE function within a
query.  Make a view first.  You can then have a process that makes a
table from this view whenever you need to export(this should be
relatively easy in the DTS designer.

Here is the SQL:

SELECT     REPLACE(CAST(quote AS VARCHAR(7999)), CHAR(13), '@@') AS
Expr1
FROM         NewQuotes
WHERE     (quote LIKE '%' + CHAR(13) + '%')

In this example, [quote] is a field in a table named [NewQuotes].

The original data looks like:
There stood a mixing bowl filled with ambrosia, while Hermes grasped the
pitcher to serve the gods.
ergfvserv
sefrgse

The output data looks like:
There stood a mixing bowl filled with ambrosia, while Hermes grasped the
pitcher to serve the gods.@@ergfvserv@@sefrgse.

BTW you should also look for Char(10) which is the line feed, char (13)
is the carriage return.

One other thing, I used the CAST function because my original column was
ntext datatype, which cannot be used with the REPLACE function.

Everyone else, please don't flame me for suggesting a Microsoft solution
on this listserv.  He is starting out there, and this is the easiest way
to deal with the problem.

Let me know if I can help more.

Cheers,

matthew


Matthew Lange
Infosoph.com
721 Barcelona Ave.
Davis, CA  95616
=20
voice:  916-275-1602
email:  infosophist@infosoph.com
=20
=20

-----Original Message-----
From: vox-tech-admin@lists.lugod.org
[mailto:vox-tech-admin@lists.lugod.org] On Behalf Of Richard Crawford
Sent: Monday, June 07, 2004 9:20 AM
To: vox-tech@lists.lugod.org
Subject: [vox-tech] Re: Changing data with awk

Apologies for breaking the thread.  I'm reading various responses on the
LUGOD website, since the e-mails are stuck on my computer at home, so
I'm
replying from SM.

Jay wrote, quoting Mark,

>> Yes, "\n" terminates a record.  But Richard (the original poster)
said
>> that the field has embedded "carriage return" characters, which is
"\r".
>> Since "\r" is not "\n", the codes do work... at least under *NIX.
>>
>> Yes, pressing the "Enter" key produces carriage return code on a
standard
>> keyboard (ASCII 13 "\r"), but *NIX translates it to the linefeed code
>> (ASCII 10 "\n"), whereas DOS/Windows translates it to carriage return
>> followed by linefeed "\r\n", and the older MacOS (before 10) doesn't
>> translate it at all.  And by convention "\n" under C (along with
various
>> other languages) represents the default line terminator for that
platform
>> ("\n" for *NIX, "\r\n" for DOS/Windows, "\r"  under older MacOS.)
But
>> unlike DOS/Windows, UNIX Lets you turn off the translation using
termios.
>> But now we're off topic... -_-v
>>
>> -Mark

>Thanks Mark, I wasn't aware of those subtleties.
>
>But, I'm betting Richard has embedded ASCII 10s in his file, and that
>is why SQLLoader (Oracle's mass data loading tool, which uses ASCII 10s
>as it's record separator) is giving him problems.
>
>Richard, wha'chu'got in your file?
>
>Jay

Here's the scoop.

I've got a moderately-sized table in our database (only 35,000 records)
which is part of our messaging system.  One of the fields, "msgMessage",
contains the text of e-mail messages sent from students to instructors,
and vice versa (don't question me about the logic of this approach; I
didn't design the system, I'm just stuck with it -- heh).  Since many of
these messages have carriage returns as line breaks, they're in the data
for this field for this table.

So I'm using a Windows program, DBArtisan, to export the table into an
external .DAT file, using the caret, ^, as the field separator.  I'm
using
SQL Loader to create the control file which I'll use to load the data
from
this .dat file into Oracle.  Unfortunately, while SQL Loader understands
the ^ field separator just fine, it interprets ALL carriage returns as
end-of-records, whether it really is at the end of the record or within
the msgMessage field.  Thus, the carriage returns in Field 6 are
interpreted as end-of-records.  That's something I didn't really think
through before.

You'd think that this would be a common problem, but I have yet to find
a
solution on the web or with any sort of tech support.  I wish there were
a
way to fix the data in the tables before exporting from SQL Server, but
there doesn't seem to be an easy way to do that.

--=20
Sl=E1inte,
Richard S. Crawford (AIM: Buffalo2K)
http://www.mossroot.com   http://www.stonegoose.com/catseyeview
"You cannot trust your judgement if your imagination is out of focus."=20
--Mark Twain


_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech