|
This is a follow-up to this dbisqlc question: Using the redirection operator &> in a batch seems to work only with a command and not with a command file. At least some tests with SA 10.0.1.4181 seem to imply that:
Is this a known limitation with dbisqlc? |
|
When dbisqlc has just one command line argument, it assumes it is a filename. When there are multiple, it assumes it is a SQL statement. To get the behaviour you are looking for, change it into a SQL statement by using a dbisql 'READ' statement explicitly: dbisqlc read command_file ">&" output.txt -john. Thanks, John - that seems to work generally. However, when the command file itself has another READ statement (as in my case), that does not work: After the inner READ statement is executed, I get a "wrong file number" error. - In contrast, when omitting output redirection, then the inner file and the rest of the outer file are executed successfully - both when specifying the outer command file on the command line directly or as a READ statement. Is output redirection limited to only one level of READ statements?
(16 Mar '11, 16:52)
Volker Barth
@Volker: that would be a bug and I think it is independent of the original question. I'll see if it is easy to fix but, as you know, dbisqlc isn't supported anymore. In the mean time, you could try the java dbisql or just avoid nesting redirections.
(17 Mar '11, 16:40)
John Smirnios
Replies hidden
John, I'm aware of the dbisqlc limitation (though we both know that there have been a few improvements lately:)). And I agree that this is a different question but it came up in the same context - I used a nested script and with that, output redirection (which I hadn't used so far) failed...
(18 Mar '11, 04:36)
Volker Barth
Comment Text Removed
No need to fix this, I'm gonna either avoid a nested script or avoid the output redirection... Using DBISQL is no option as we don't want to deploy the Java tool to clients. - FWIW: The initial idea was to optionally set the OEM connection string in a reload.sql via a nested script (which would be empty for non-OEM setups).
(18 Mar '11, 04:53)
Volker Barth
1
Yes, some fixes to dbisqlc do get made -- generally by me. I like the tool so I don't mind making some fixes to it. I really wish it had draggable column widths... and Unicode support, and... and... Sigh, well, maybe someday. I've already made a tentative fix for the output redirection but it requires some testing yet. -john.
(18 Mar '11, 09:43)
John Smirnios
Thanks - it's pretty smart to use the developers's favourite tools, too, isn't it:)
(18 Mar '11, 10:13)
Volker Barth
Obviously fixed as CR 666434 in 12.0.1.3329, 12.0.0.2670 and 11.0.1.2591. - I don't know whether this is going to be fixed in 10.0.1, either. Thanks again, John!
(29 Apr '11, 19:07)
Volker Barth
10.0.1 is in limited support and you had also decided that there was "no need to fix this" so I did not put the change into 10.0.1.
(02 May '11, 10:17)
John Smirnios
Man, I wasn't aware I had such detailed influence on what gets fixed:) But as I actually had stated, I can cope with 10.0.1 not having this fix: I finally realized that the particular setting of the OEM connection string as part of the reload (which was used as a nested script) is not necessary at all - as dbisqlc is self-authenticating. Another lesson learnt:)
(02 May '11, 11:27)
Volker Barth
|
