[Solved] Problem with FileReadLine

[readmedottxt]

Hello,

Trying to monitor (and provide feedback) for an unattended installation of SP2 for SQL 2005 by watching

C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt

I'm reading lines and reporting to a master DB various things like time began, progress, errors and completion from reading the log file.

Here's some code:

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 0)
        if $f = -1 then msgbox(0, "", "Could not open logfile")
        $line = ""
        While 1
            $l = FileReadLine($f)
            if @error then ExitLoop
            if StringLeft($l, 27) = "Product  " Then; had to use 'product  ' with 2 spaces so 'product version' is ignored
                $l2 = StringSplit($l, ":", 1)
                $l3 = StringStripWS($l2[2], 1)
            EndIf
            
            if StringLeft($l, 7) = "Status " Then
                $l4 = StringSplit($l, ":", 1)
                $l5 = StringStripWS($l4[2], 1)
                
                $line = $line & $l5 & ": " & $l3 & @CRLF
            EndIf
        WEnd
        if $line <> $line2 Then
            GUICtrlSetData($Report, $line)
            $line2 = $line
        EndIf

        FileClose($f)

I've had no luck here. If I open the text file in notepad and save it without changing anything, the code will correctly process and parse Summary.txt

So I opened the before and after Summary.txt files in xvi32 (win32 hex editor) and found two discrepancies:

Before saving with Notepad (as output by SP2) the text starts immediately, with the first word (represented in hex) being "Time"

54 00 69 00 6D 00 65 00

This cannot be read by the code. FileReadLine only returns one character "T" then every subsequent line read is blank.

After saving with Notepad, we get a leading FF FE before "Time"

FF FE 54 00 69 00 6D 00 65 00

Now it works correctly - the code can read and parse the code, I get the results I need.

Is this a bug in AutoIt or the way SP2 for SQL 2005 writes its text files?

How could I work around this?

Edited March 10, 2009 by readmedottxt

[readmedottxt]

I've attached the logfiles I referred to above if that helps.

Thanks

SQLSP2Logs.zip

[enaiman]

Wow - took me a while to find a way.

I didn't believe what you were saying at the begining but I've seen that it was true.

I tried to get the text from DOS, using StdOUT, reading the file, reading lines ... nothing worked.

Finally I've found a "messy way" to do it: to open it in a hidden notepad window and get the text and closing it after that.

It is messy because I use another app to get the text content and I'm using "Control" commands (which depend on using app's title ...)

You will have to change my script to reflect your file's location (pay attention to Run command when file path contain white spaces) and the notepad window's title. If you do this, you will be fine.

Run("notepad C:\temp\original.txt", "",  @SW_HIDE)              ;open the file (hidden)
Sleep(200)                                                      ;give time to open
$content = ControlGetText("Original.txt - Notepad", "", "Edit1");get text
MsgBox(0, "Content", $content)
WinKill("Original.txt - Notepad")                               ;kill hidden notepad

[Skruge]

It helps to understand why it isn't working, and what the notepad workaround is actually doing.

Seeing every other byte value as zero is a dead giveaway that you're dealing with Unicode data.

The problem is that there are several Unicode formats, and in order to determine which is in use, there's usually a Byte Order Mark (BOM) added to the beginning of the file. (That's what notepad did for you).

See this page for more information: http://unicode.org/faq/utf_bom.html

Now, it could be that SQL forgot to add the BOM, or maybe it tried to do it when it was finished writing but your script or some other process held the file open.

Without this data, AutoIt coudn't tell what format it was and defaulted to ANSI.

Either way, you can force AutoIt to open the file in UTF-16 mode by using FileOpen's mode 32.

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 32)

The moral of the story?

The wonderful thing about standards is that there are so many of them to choose from.

[enaiman]

Thanks Skruge - that solved everything. Too bad I had no idea about that (It would have saved me some time) and I didn't think to play with different modes for opening a file.

Anyway - today I have learned something new Isn't that wonderful?

[readmedottxt]

Wow - took me a while to find a way.

I didn't believe what you were saying at the begining but I've seen that it was true.

I tried to get the text from DOS, using StdOUT, reading the file, reading lines ... nothing worked.

I tried all that too, I couldn't believe such a simple piece of code wasn't working as it should.

It helps to understand why it isn't working, and what the notepad workaround is actually doing.

Seeing every other byte value as zero is a dead giveaway that you're dealing with Unicode data.

The problem is that there are several Unicode formats, and in order to determine which is in use, there's usually a Byte Order Mark (BOM) added to the beginning of the file. (That's what notepad did for you).

See this page for more information: http://unicode.org/faq/utf_bom.html

Now, it could be that SQL forgot to add the BOM, or maybe it tried to do it when it was finished writing but your script or some other process held the file open.

Without this data, AutoIt coudn't tell what format it was and defaulted to ANSI.

Either way, you can force AutoIt to open the file in UTF-16 mode by using FileOpen's mode 32.

$f = FileOpen("C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\HotFix\Summary.txt", 32)

The moral of the story?

Prior to reading the link, I had some knowledge on LE & BE encoding (x86 vs 68xxx days) but since it hasn't intefered with my work for a decade, I didn't think it could be affecting "plain" text files from the same platform....

Something so simple and straightforward, yet so frustrating when you dont understand and apply the technology.

Thank you for the explanation! Like eniaman said, you learn something new every day.