Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

LF / Char(10) / 0x0A: Appending via Win2K Command Line

13 views
Skip to first unread message

Jimmy May

unread,
Aug 13, 2001, 4:23:56 PM8/13/01
to
I have a buggy SQL Server 2000 DTS package which must be
coaxed to import the last row of a file. If I view my raw
source ASCII file in hex, each row ends in 0xA0, i.e., a
linefeed. Though the row terminator is defined as LF
within the DTS package, the last row is ignored UNLESS
there is an extra LF or CRLF. If I open the file manually
before importing it, I can use an application called
TextPad, browse to the end of the file, hit ENTER, save,
and see that the hex value added is 0x0A. The file runs
perfectly--all rows including the last one, are imported.
If I use NotePad to edit it, I get a carriage return as
well as a line feed added, but the package runs fine
anyway. I've learned that supposedly I can append an empty
line to a file by using

echo. >>MyFile

However, this actually adds three characters, a character
0x20, then 0x0D 0xOA--and this cacks the job.

Here's a summary:
TextPad 0A Successful, but must be run manually
NotePad 0D 0A Successful, but must be run manually
echo 20 0D 0A Not success, but can be run via batch file

I realize I can create a file containing only one
character, 0x0A, and append that to the end of my source
file, but that seems like a kludge. Also, I'm sure I
could use an ActiveX script to do this, but that seems
like a sledgehammer approach.

I have so far been unsuccessful determining how to do this
on the command line--but it can't be that tough, can it?

I'm running SQL Server 2000 Enterprise edition SP1 on
Windows 2000 Advanced Server SP2 (but it seems to be
independent of the service packs).

Neil Pike

unread,
Aug 14, 2001, 3:04:42 PM8/14/01
to
Jimmy,

That does sound like a bug. What I'd use to work around it is a tool like
sr32 - www.funduc.com - which can be run from the command line and turn all the
LF's into CRLF's. (This is a very minimal use of a very powerful tool).

Neil Pike MVP/MCSE. Protech Computing Ltd
(Please post ALL replies to the newsgroup only unless indicated otherwise)


Tom Olson

unread,
Aug 14, 2001, 6:28:16 PM8/14/01
to

Search and Replace (sr32) can be a real life saver. Very good product!

"Neil Pike" wrote:
>...


> That does sound like a bug. What I'd use to work around it is a tool
like
> sr32 - www.funduc.com - which can be run from the command line and turn
all the
> LF's into CRLF's. (This is a very minimal use of a very powerful tool).

> ...


HSalim

unread,
Aug 14, 2001, 7:38:23 PM8/14/01
to
Actually, it is not buggy, it is a problem with your source data
You are using a Unix Source file - you see unix uses only LFs for a newline
whereas
WIN/DOS uses CRLF for a newline.
(macs use CR only)

in any case, your sledgehammer approach is what you need - except you can
do it just as elegantly.
Just add an activex script to your DTS and paste this code there

Function Main
const ForAppending = 8
set ofso = createObject(scripting.FileSystemObject)
set Myfile = ofso.OpenTextFile("c:\folder1\Subfolder2\thisfile.txt",
forappending, True)
Myfile.write vbLf
Myfile.close
set ofso = nothing
Main = DTSTaskExecResult_Success
End Function

Regards
Habib

"Jimmy May" <jm...@openglobe.net> wrote in message
news:1207f01c12435$e0e9f460$b1e62ecf@tkmsftngxa04...

0 new messages