Adding to above one,I get the below error.
Sudheer, You don't have to configure FastLoad scripts. It uses the JDBC FastLoad option, assuming not column data type issues.
The failure above can happen if the database you are loading into does not respond and causes the pipe to close on the export side. Does this happen each time or temporary performance issue on loading database? Also, what version of Studio are you running?
fgrimmer,If I try giving a filter condition it loads fine. I face the said error when I go for full table refresh(2 million recs). For your question,it happens all the times and am using Teradata Studio 15.10.
Sudheer, Can you open an incident with T@YS so we can collect your error logs and configuration information to look further into this problem?
You mentioned using a filter on the data transfer. Is that on the column or data? Is that just for table load? Are you able to use the filter for table copy?
I wil raise a ticket.
Actually I was able to export and load the data after installing utilities in my local drive. But it's clearly visible in my case that Teradata studio was using regular EXPORT/IMPORT options as in SQL assistant. It took me around 45 mins to load 2 miliion records.
Sudheer, Thanks. Please attach the DDL for your table, if that is possible, so we can see if there are any issues with column datatypes. You mention installing on local drives. How were you running Studio prior to that?
I'm creating a fairly simple stored procedure in Studio. When I compile it, if there are errors, it doesn't display the line numbers like SQLA does, so not easy to debug, as just get "Syntax error: Invalid SQL statement".
I also have a case that the stored procedure compiles fine in SQLA, but not in Studio.
Have you got ant suggestions.
"New Teradata Studio Administration User Experience" POST:
Randy, I am seeing the statement fails with [3606 : 42000] Syntax error: Invalid SQL Statement when the comment comes before the REPLACE PROCEDURE.
I found a similar post on our Studio Forum and a detailed explanation from Tom Nolan:
The Teradata Database requires a special wire protocol to be used for the CREATE PROCEDURE and REPLACE PROCEDURE statements, that is slightly different than the wire protocol used for all other SQL statements.
Because of the need to use a different wire protocol, the Teradata JDBC Driver must examine the SQL request text and determine whether or not each SQL statement is CREATE/REPLACE PROCEDURE.
If you place a comment before the CREATE/REPLACE PROCEDURE keywords, then you will confuse the Teradata JDBC Driver, it won't recognize the SQL statement as CREATE/REPLACE PROCEDURE, and then it will send the SQL request to the Teradata Database using the normal wire protocol, and you will get the 3706 syntax error.
For comparison, BTEQ deals with this issue by forcing the user to put a CREATE/REPLACE PROCEDURE in a separate file, and use the special .COMPILE command to submit the CREATE/REPLACE PROCEDURE command to the Teradata Database. That is also a clunky workaround.
There is an outstanding RFC 94094 against the Teradata Database to remove the need for the special wire protocol for CREATE PROCEDURE and REPLACE PROCEDURE statements.
I dug a little deeper and found the post above. When I removed the comment at the start of the SP, the compile worked, and if an error the line number was displayed in the error message.
Is there any way in Studio to use the similar option in SQLA of "Write all exported answer sets to a single file" ?
For example I generate a set of SHOW statements and want to export all their output to a single file, so that I can then modify the whole set and then execute again.