Too many SQL's from SP Business Objects Data Integrator

Connectivity
Teradata Employee

Too many SQL's from SP Business Objects Data Integrator

I am having an issue where a Transform request from the SAP BO ETL tool Data Integrator is creating additional SQL to the DBC (examples below).  We are using the native bulk load option (insert/select) via ODBC connection.  I want to eliminate the additional SQL's that are being generated.  Is there an option/setting in ODBC or Data Integrator that anyone knows of that generates these types of addiotnial overhead SQL?  It is causing unnecessary resource utilization.  Anyhelp is appreciated. 

Thanks,

Dennis

  1.  HELP SESSION
  1. HELP TABLE "mdm_nc"."NC_STANDARD_0007_MAP"
  1.  SELECT TRIM(TRAILING FROM COLUMNNAME) FROM DBC.COLUMNS WHERE  UPPER(TRIM( TRAILING FROM COLUMNNAME )) LIKE UPPER(TRIM(TRAILING FROM 'SOURCE_CODE')) ESCAPE '\' AND UPPER(TRIM(TRAILING FROM DATABASENAME )) LIKE UPPER(TRIM(TRAILING FROM 'MDM_NC')) ESCAPE '\' AND UPPER(TRIM(TRAILING FROM TABLENAME )) LIKE UPPER(TRIM(TRAILING FROM 'NC_STANDARD_0007_MAP')) ESCAPE '\' GROUP BY COLUMNNAME ORDER BY 1
3 REPLIES
Teradata Employee

Re: Too many SQL's from SP Business Objects Data Integrator

1) ODBC driver submits a HELP SESSION request everytime application calls database connect function like SQLDriverConnect()

2,3 ) Seems ODBC driver generated SQLs as a result of application calling ODBC catalog functions like SQLColumns().  The result of the SQL is how ODBC driver can return data dictionary information to application.

Teradata Employee

Re: Too many SQL's from SP Business Objects Data Integrator

Thanks Vhari.  I was assuming that the application SAP BO Data Integrator was/is the cause.  However, I am unsure of were to look in order to modify a setting in the application to eliminate the additional SQLColumns(), SQLDatabase(), and SQLTable() calls.  Any thoughts/ideas.

Teradata Employee

Re: Too many SQL's from SP Business Objects Data Integrator

Sorry, I can't suggest any option related to the application as I have no knowledge of it.  I can suggest you to try changing the Teradata ODBC option, "Session Mode" from ANSI to Teradata if you have no reason to choose ANSI session mode.  The SQL generated in Teradata mode may perform little better because comparisions are case insensitive in Teradata mode, hence the SQL generated in Teradata session mode will not use UPPER() function.