I don't see anything wrong with the syntax - substituting my own file names and DSN works fine.
As a general rule I would enclose filenames in double quotes just in case they contain spaces or special characters, but your names here should be OK without quotes.
As long as you always use ODBC and your DSN contains the user/password your -c parameter should be OK.
It is generally safer to specify -p Odbc just to be certain that it will use ODBC.
( -p Td would tell it to use the Teradata.Net provider)
The only thing I can think of why -e would fail is if you dont have write permissions or if the path is incorrectly spelled.
There was a problem in earlier 13.11 versions where it did not prompt you for missing connection info (user/pwd) when this info was not provided in the -c parameter orin the DSN. that was fixed in 13.11.0.4.
There was also a problem where the app did not close after it had completed the export. That was fixed in 13.11.0.5.
I've not seen any other errors related to startup parameters though.
We recently upgraded Teradata SQL Assistant from version 7.2 to 13.11. In version 7.2 the startup command line:
C:\Program Files\Teradata\Client\13.11\Teradata SQL Assistant\sqla.exe -f K:\shared\DonutData\Bakery_Distress_Production.sql -e K:\shared\DonutData\DonutDistress.txt
Worked well and produced a text file that was processed elsewhere.
With version 13.11 the requirement of a -c parameter was added that accessed the server:
C:\Program Files\Teradata\Client\13.11\Teradata SQL Assistant\sqla.exe -f K:\shared\DonutData\Bakery_Distress_Production.sql -e K:\shared\DonutData\DonutDistress.txt -c td_prd_qd
The command runs and crashes with no export. When the export (-e) parameter was removed the command line executed just fine but did not export the data.
When the -c command parameter is removed the query opens but does not execute.
Can anyone help me with a reason/solution as to why the -e parameter is crapping on my parade?
Thanks for your help!