hi all, I need to redirect stdout to a file within a VBS script I need to
do this because I'm forced to use this SQL-DMO method:

http://msdn2.microsoft.com/de-de/library/ms141159(SQL.90).aspx

...which does not allow capturing of its stdout, since the one I need:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q279514

is broken (and has been since 2003). a response would be great!

- erick <e@arix.com>

p.s. in Ksh this would be so easy... I don't remember the syntax exactly but
it would be something like: exec > /tmp/myfile

Re: redirecting stdout?? by Bob

Bob
Tue Mar 14 13:34:47 CST 2006

ekkis wrote:
> hi all, I need to redirect stdout to a file within a VBS script I
> need to do this because I'm forced to use this SQL-DMO method:

Why can't you use ADO? This problem would be trivial ...


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by ekkis

ekkis
Wed Mar 15 11:16:04 CST 2006

> Why can't you use ADO? This problem would be trivial ...

hmm... I guess just because I'm not that Microsoft savvy and didn't know
about ADO (nor why there would be two ways to get at a SQL Server).

but I'll google. thx for the tip!

Re: redirecting stdout?? by ekkis

ekkis
Wed Mar 15 12:06:27 CST 2006

> Why can't you use ADO? This problem would be trivial ...

ok, I've done some reading on ADO and I've managed to make a connection and
retrieve data... however, how to retrieve the output, the PRINT statements in
the SQL I hand the server is not readily apparent.

hint?

Re: redirecting stdout?? by ekkis

ekkis
Wed Mar 15 12:47:34 CST 2006

> Why can't you use ADO? This problem would be trivial ...

doesn't seem so trivial... the Error object in ADO is not scriptable (states
the documentation) and PRINT statements have to be retrieved via an event
handler, which cannot be done from VBScript.

so I'm back to having to figure out how to redirect the stdout of my
VBScript - unless am I missing something here?

help!

Re: redirecting stdout?? by Bob

Bob
Wed Mar 15 14:04:32 CST 2006

ekkis wrote:
>> Why can't you use ADO? This problem would be trivial ...
>
> doesn't seem so trivial... the Error object in ADO is not scriptable

I'm not sure what you mean by "not scriptable" ...

> (states the documentation) and PRINT statements have to be retrieved
> via an event handler, which cannot be done from VBScript.

There is a trick. In order for PRINT statements to appear in the
connection's Errors collection, the procedure or batch has to raise an error
(you can use the T-SQL RAISERROR statement to raise an error). As long as
there is an error, you can loop through the Errors collection and retrieve
the results of the print statements:

errs=conn.errors.count
if errs>1 then
'add print statement results to an array
dim ar()
redim ar(errs-2)
for i = 0 to errs - 1
set adoerr=conn.errors(i)
desc=adoerr.description
if desc<> "the error message from RAISERROR" then
ar(i) = desc
end if
next
end if

You can then use the FileSystemObject to create or open a text file (using
OpenTextFile) and write the contents of the array to the file.

HTH,
Bob Barrows

PS. There is more to this if your procedure or batch is returning resultsets
as well as print statement results
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by Bob

Bob
Wed Mar 15 14:08:13 CST 2006

ekkis wrote:
>> Why can't you use ADO? This problem would be trivial ...
>
> doesn't seem so trivial... the Error object in ADO is not scriptable
> (states the documentation) and PRINT statements have to be retrieved
> via an event handler, which cannot be done from VBScript.
>
> so I'm back to having to figure out how to redirect the stdout of my
> VBScript - unless am I missing something here?
>
OK, you just stated in your new thread that you are returning resultsets as
well as print statement results. That makes it a little more difficult, but
not impossible.

I assume you are running a stored procedure, is that correct?

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by ekkis

ekkis
Wed Mar 15 14:36:27 CST 2006

> There is a trick. In order for PRINT statements to appear in the
> connection's Errors collection, the procedure or batch has to raise an error

that's kinda poor but I guess I can append a raiserror to the SQL I'm about
to execute and at this point I'm just glad I can do it at all... I hope it
doesn't expect a raiserror _per_batch_ (I have multiple batches (separated by
"go") in the files I will be loading).

> PS. There is more to this if your procedure or batch is returning resultsets
> as well as print statement results

yeah, I realise that but I've got that covered.

thank you so much for the input. I really appreciate it as I've now spend
waaay more time than is reasonable in getting a relatively simple thing to
work.

thanks again!

Re: redirecting stdout?? by Bob

Bob
Wed Mar 15 14:41:00 CST 2006

ekkis wrote:
>> There is a trick. In order for PRINT statements to appear in the
>> connection's Errors collection, the procedure or batch has to raise
>> an error
>
> that's kinda poor but I guess I can append a raiserror to the SQL I'm
> about to execute and at this point I'm just glad I can do it at
> all... I hope it doesn't expect a raiserror _per_batch_ (I have
> multiple batches (separated by "go") in the files I will be loading).
>
>> PS. There is more to this if your procedure or batch is returning
>> resultsets as well as print statement results
>
> yeah, I realise that but I've got that covered.
>
> thank you so much for the input. I really appreciate it as I've now
> spend waaay more time than is reasonable in getting a relatively
> simple thing to work.
>
So are you all set now?

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by ekkis

ekkis
Thu Mar 16 12:01:27 CST 2006

> There is a trick. In order for PRINT statements to appear in the
> connection's Errors collection, the procedure or batch has to raise an error

I've taken your code and suggestion but am failing to make it work... In
the code below, I have tried 3 variations on the SQL to execute with the
following results:

1. breaks the script with the raiserror string displayed on a popup dialogue
i.e. the wscript.echo never runs
2. displays the results (wscript.echo runs correctly) but shows 0 errors.count
3. breaks the script with error on line 16 (rs.MoveFirst) and the message:
"Operation is not allowed when the object is closed", Source: ADODB.Recordset

I'm a bit at a loss, maybe you could point out what I'm missing....

- e

-- my script
--------------------------------------------------------------------------
s = "UA.Merlin"
x = Split(s, ".")

Set srv = CreateObject("ADODB.Connection")
'Set rs = CreateObject("ADODB.Recordset")

DSN = "Provider = SQLOLEDB;Data Source=" & x(0) & ";"
DSN = DSN & "Trusted_Connection=Yes;"
DSN = DSN & "Initial Catalog=" & x(1) & ";"
srv.open DSN

dim rs
'set rs = srv.Execute("raiserror('ERR', 11, 1, 1) select v=@@version print
'YAYA'")
'set rs = srv.Execute("select v=@@version print 'YAYA' raiserror('ERR', 11,
1, 1)")
set rs = srv.Execute("print 'YAYA' select v=@@version raiserror('ERR', 11,
1, 1)")
rs.MoveFirst
wscript.echo "Results: " & rs(0)

errs = srv.errors.count
wscript.echo errs

if errs > 1 then

for i = 0 to errs - 1
set adoerr = srv.errors(i)
desc = adoerr.description
if desc <> "the error message from RAISERROR" then
wscript.echo desc
end if
next
end if

rs.Close


Re: redirecting stdout?? by Bob

Bob
Tue Mar 21 13:01:48 CST 2006

ekkis wrote:
>> There is a trick. In order for PRINT statements to appear in the
>> connection's Errors collection, the procedure or batch has to raise
>> an error
>
> I've taken your code and suggestion but am failing to make it work...
> In
> the code below, I have tried 3 variations on the SQL to execute with
> the following results:

I don't know how I missed this.
I'm a little busy right now but I will look at it later.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by Bob

Bob
Thu Mar 23 09:16:10 CST 2006

Bob Barrows [MVP] wrote:
> ekkis wrote:
>>> There is a trick. In order for PRINT statements to appear in the
>>> connection's Errors collection, the procedure or batch has to raise
>>> an error
>>
>> I've taken your code and suggestion but am failing to make it work...
>> In
>> the code below, I have tried 3 variations on the SQL to execute with
>> the following results:
>
> I don't know how I missed this.
> I'm a little busy right now but I will look at it later.
>

I was away from the keyboard all day yesterday so I will not be able to
address this until later today. Sorry about that.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by Bob

Bob
Fri Mar 24 08:24:53 CST 2006

Bob Barrows [MVP] wrote:
> Bob Barrows [MVP] wrote:
>> ekkis wrote:
>>>> There is a trick. In order for PRINT statements to appear in the
>>>> connection's Errors collection, the procedure or batch has to raise
>>>> an error
>>>
>>> I've taken your code and suggestion but am failing to make it
>>> work... In
>>> the code below, I have tried 3 variations on the SQL to execute with
>>> the following results:
>>
>> I don't know how I missed this.
>> I'm a little busy right now but I will look at it later.
>>
>
> I was away from the keyboard all day yesterday so I will not be able
> to address this until later today. Sorry about that.
>
OK, I had a few minutes this morning and I did make some progress (I was
able to see content of the recordset as well as the error message from the
raiserror, but i was not able to get the PRINT). You will find my code at
the end. As you will see, I had to jump through quite a few hoops.

I am out of time, but I do want to mention:
1. The T-SQL Print statement is NOT stdout. If it was, it would print to a
DOS window, correct? It is intended to print output to the Query Analyzer
application.
2. ODBC and OLE DB have a long history of not being able to reliably handle
the results of multiple PRINT and RAISERROR statements. See Erland
Sommarskog's error-handling series at http://www.sommarskog.se/index.html

I would suggest using a different technique to get the strings you want to
use PRINT to return, either an output parameter or select statements (you
can use NextRecordset to retrieve multiple resultsets.). Instead of

set rs = srv.Execute("print 'YAYA'; " & _
"select v=@@version; raiserror('ERR', 11,1, 1)",,1)

Use

set rs = srv.Execute("select 'YAYA'; " & _
"select v=@@version; raiserror('ERR', 11,1, 1)",,1)




dim srv,objRS, ar(), i, adoerr, errs
s = "UA.Merlin"
x = Split(s, ".")
Set srv = CreateObject("ADODB.Connection")

'DSN = "Provider = SQLOLEDB;Data Source=" & x(0) & ";"
'DSN = DSN & "Trusted_Connection=Yes;"
'DSN = DSN & "Initial Catalog=" & x(1) & ";"
srv.open DSN
on error resume next

dim rs
set rs = srv.Execute("print 'YAYA'; " & _
"select v=@@version; raiserror('ERR', 11,1, 1)",,1)
if err<> 0 then
msgbox err.description,,"ADO Error After Initial Open"
end if
for j=0 to 4
if rs.state=0 then
err.clear
set rs=rs.nextrecordset
if err<>0 then
msgbox err.description,,"ADO Error After MoveNext"
errs = srv.errors.count

if errs > 1 then

for i = 0 to errs - 1
set adoerr = srv.errors(i)
desc = adoerr.description
if desc <> "ERR" then
wscript.echo "srv.errors(i) contained " & desc
end if
next
end if

end if
else
exit for
end if
next
if not rs.eof then
err.clear
wscript.echo "Results: " & rs(0)
set rs=rs.nextrecordset
if err<>0 then
wscript.echo "ADO error contained " & vbcrlf & err.description

errs = srv.errors.count
wscript.echo "Error count - " & errs

if errs > 1 then

for i = 0 to errs - 1
set adoerr = srv.errors(i)
desc = adoerr.description
if desc <> "ERR" then
wscript.echo "srv.errors(i) contained " & desc
end if
next
end if
end if
rs.Close
errs = srv.errors.count
wscript.echo "Error count - " & errs

if errs > 1 then

for i = 0 to errs - 1
set adoerr = srv.errors(i)
desc = adoerr.description
if desc <> "ERR" then
wscript.echo "srv.errors(i) contained " & desc
end if
next
end if
end if
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.



Re: redirecting stdout?? by ekkis

ekkis
Sun Mar 26 16:51:50 CST 2006

> I had to jump through quite a few hoops.

your original reply comes echoing back :)

"Why can't you use ADO? This problem would be trivial ..."

> 1. The T-SQL Print statement is NOT stdout. If it was, it would print to a
> DOS window, correct?

that is correct, as I found out after my initial posting here.

> 2. ODBC and OLE DB have a long history of not being able to reliably handle
> the results of multiple PRINT and RAISERROR statements.

this is why I just cringe at the thought any time I have to deal with M$
technologies. what pathetic garbage. I've now spent days f**king around
with something I could have done in a Linux/perl environment in no time.

> I would suggest using a different technique to get the strings you want to
> use PRINT to return, either an output parameter or select statements (you
> can use NextRecordset to retrieve multiple resultsets.). Instead of

yeah, no can do, I have no control over the scripts I need to run. oh well.
I really need to steer this shop into Linux.

thx for your efforts.