Can I use dbisqlc with a command file and output redirection?

[VolkerBarth]

This is a follow-up to this dbisqlc question:

Using the redirection operator &> in a batch

dbisqlc command ">&" output.txt

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:

• When I omit the output redirection, dbisqlc treats the command line argument (which is file path) as SQL file (as wanted).
• However, when I add the output redirection, dbisqlc tries to interpret the file name as an SQL command and fails obviously.

Is this a known limitation with dbisqlc?

[johnsmirnios · Accepted solution]

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.

[VolkerBarth · Accepted solution]

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?

[johnsmirnios · Accepted solution]

@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.

[VolkerBarth · Accepted solution]

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...

[VolkerBarth · Accepted solution]

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).

[johnsmirnios · Accepted solution]

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.

[VolkerBarth · Accepted solution]

Thanks - it's pretty smart to use the developers's favourite tools, too, isn't it:)

[VolkerBarth · Accepted solution]

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!

[johnsmirnios · Accepted solution]

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.

[VolkerBarth · Accepted solution]

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:)