By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,089 Members | 1,152 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,089 IT Pros & Developers. It's quick & easy.

Redirect SELECT results to a file

P: n/a
This should be simple, and the docs say so, but no...

1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command

If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.

The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".

I don't think it should be so difficult. Nothing at the DB2 site
that I could find explains why this doesn't work.

winXP/SP2, UDB v8.2.9
Jul 8 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
MeBuggyYouJane wrote:
This should be simple, and the docs say so, but no...

1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command

If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.
A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):

EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).

In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.

So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".
-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).

I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
I don't think it should be so difficult.
That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.

[1]
http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.doc/doc/r0002036.html
Cheers,

Dave.
Jul 8 '08 #2

P: n/a
Dave Hughes wrote:
MeBuggyYouJane wrote:
>This should be simple, and the docs say so, but no...

1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command

If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.

A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):

EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).

In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.

So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
>The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".

-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).

I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
>I don't think it should be so difficult.

That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.

[1]
http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.doc/doc/r0002036.html
Cheers,

Dave.
Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.

No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.

thanks.
Jul 9 '08 #3

P: n/a
MeBuggyYouJane wrote:
Dave Hughes wrote:
>MeBuggyYouJane wrote:
>>This should be simple, and the docs say so, but no...

1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command

If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.

A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):

EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).

In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.

So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
>>The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".

-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).

I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
>>I don't think it should be so difficult.

That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.

[1]
http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.doc/doc/r0002036.html
Cheers,

Dave.

Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.

No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.

thanks.
Turns out to be from either WshShell or windoze itself. I was able to
get the syntax to work from db2cmd directly. Didn't, and can't, see why
it should be different from the shell. But from the shell it will only
write to a directory local file. Better than nothing. oh well.

thanks.
Jul 10 '08 #4

P: n/a
On Jul 10, 2:33 am, MeBuggyYouJane <gnuo...@rcn.comwrote:
MeBuggyYouJane wrote:
Dave Hughes wrote:
MeBuggyYouJane wrote:
>This should be simple, and the docs say so, but no...
>1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command
>If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.
A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):
EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).
In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.
So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
>The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".
-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).
I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
>I don't think it should be so difficult.
That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.
[1]
http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.doc/doc/r0002036.html
Cheers,
Dave.
Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.
No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.
thanks.

Turns out to be from either WshShell or windoze itself. I was able to
get the syntax to work from db2cmd directly. Didn't, and can't, see why
it should be different from the shell. But from the shell it will only
write to a directory local file. Better than nothing. oh well.
Just a thought, did you use an absolute or relative path? Also, is it
a local disk, or is it mounted somehow?
/Lennart

Jul 10 '08 #5

P: n/a
Lennart wrote:
On Jul 10, 2:33 am, MeBuggyYouJane <gnuo...@rcn.comwrote:
>MeBuggyYouJane wrote:
>>Dave Hughes wrote:
MeBuggyYouJane wrote:
This should be simple, and the docs say so, but no...
1) I have an .hta file (VBScript), with a call to windoze shell
2) the shell call is to db2cmd, input from a file
3) the command file has a db2 SELECT <blah command
If I insert foo.txt in the db2cmd command line, the
commands, result set, and messages go to foo.txt. That's sort
of OK, except that running EXPORT, i can concoct the command
with a file for output, and the result goes there. The client
wants both the SELECT and EXPORT to work the same: result
set in a file.
A quick word of caution regarding this: EXPORT's output is
fundamentally different (in purpose) to the captured output of a SELECT
statement executed by the CLP (e.g. via -r or a stdout redirection):
EXPORT is meant for data transfer, pure and simple. So, EXPORT outputs
data unambiguously in specifically structured formats (IXF, delimited,
fixed width).
In contrast, the CLP's output is meant for human consumption - /not/
for data transfer. Hence the CLP takes certain liberties in its output.
Columns are truncated at 8kb (e.g. CLOB or big VARCHARs), NULLs are
represented by a "-" (which can't be distinguished from a CHAR column
containing a "-"), dates are formatted into the client's locale, etc.
etc.
So - nothing wrong with wanting them to work similarly, but I'd be very
wary of somebody wanting to use them for the same purpose. Anyway...
The docs say that I can insert -r foo.txt in either the
db2cmd command line or the db2 command line, and get the
result of the SELECT in foo.txt. Nope. Windoze creates foo.txt,
but db2 errors with "unable to access file".
-r is an option for db2, not db2cmd. db2cmd is simply a shell used on
Windows to provide the necessary environment for db2. The only options
it takes are -i, -w, -c, and -t [1]. I tried out -r on both Linux and
Windows sessions and it seemed to work fine (no mysterious access
errors).
I've no idea why DB2 would say it can't access the file when it's been
created successfully, unless the file already existed and the user
executing the CLP doesn't have the necessary privileges to overwrite
the file.
I don't think it should be so difficult.
That's because it's not ;-). I suspect there may be a problem with the
command line you're using, or the way you're invoking the CLP. Can you
post the /exact/ command line you're using, along with the output? If
you're launching the CLP from an application the code for launching the
CLP would be good too.
[1]
http://publib.boulder.ibm.com/infoce.../com.ibm.db2.l
uw.admin.cmd.doc/doc/r0002036.html
Cheers,
Dave.
Yes, they're different. The client just doesn't want/need the commands
and messages. Makes sense. And the error code flashed by before I
caught it: DB21005E. But that just translates to can't use the file.
No Google Groups or usenet in cubeland, so it'll have to be on the
morrow. I did find an APAR for that code, but not quite the same symptom.
thanks.
Turns out to be from either WshShell or windoze itself. I was able to
get the syntax to work from db2cmd directly. Didn't, and can't, see why
it should be different from the shell. But from the shell it will only
write to a directory local file. Better than nothing. oh well.

Just a thought, did you use an absolute or relative path? Also, is it
a local disk, or is it mounted somehow?
/Lennart
All local. It's clear that there is some pathological interaction among
DB2/windoze/WshShell. If nothing else, the users and permissions
differ between the local directory and non-local directory file. The
local has DB2ADMNS and DB2USERS defined.

For now, they'll have to live with getting the SELECT listing in the
..hta file's directory.

thanks.
Jul 12 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.