Problems with Teradata ODBC connector

[#1]

Hi everyone.

I have a fresh install of QV Server with external Publisher server. 11.20 SR7

ODBC connectors work fine except for the Teradata and it's a show stopper.

Desktop client reloads no problems.  QMC task hates it but has no issues with other connections

It's established via system dsn with the ID with access to the Tera db

.  I've reinstalled the Tera utilities suite v15.  The TPT connector starts the load but fails at the SQL select statement - with or with out data sense.

Error:

(2015-01-13 17:39:58) Error: QDSMain.Exceptions.DistributionFailedException: Distribute failed with errors to follow. ---> QDSMain.Exceptions.ReloadFailedException: Reload failed ---> QDSMain.Exceptions.LogBucketErrorException: The Source Document was NOT reloaded successfully. DocumentPath=\\<server>\<file location path>\Test.qvw.

(2015-01-13 17:39:58) Error: at QDSMain.ReloadTask.VerifyConditions(TaskResult taskResult)

(2015-01-13 17:39:58) Error: at QDSMain.ReloadTask.Reload(String fileName, TaskResult taskResult, String sectionAccessUserName, String sectionAccessPassword, eReloadOptions reloadOption, String variableName, String variableValue, Boolean moniterCpuUsage)

(2015-01-13 17:39:58) Error: --- End of inner exception stack trace ---

This is peculiar.  Let me know if everyone has an idea to try or feedback to answer further inquiries.

Thanks.

Jayson

[Colin-Albert]

It looks like you connector is 32-bit as the error you posted before refers to "tdata32.dll".

I would try using CONNECT32, but you will need to check that you are accessing the 32-bit ODBC configuration in control panel and not the 64-bit ODBC configuration.

[#3]

It is making the brain work on this one.  The OS, report, Teradata server are all 64b but the Tera ODBC makes it appear 32b even from teh 64b tera folder location.

Thanks for the suggestion, originally I applied the 32b ODBC this morning as a baseline to diagnose it and just the last hour switched to the 64b.

The Tera SQL Admin app that comes in the suite does make a connection to the tera server and can run a select count(*) from any table.

This is leading me to figure there's a Publisher and Tera miscommunication somewhere.

Thanks Colin, Your help is appreciated.

[Colin-Albert · Accepted solution]

Can you install QV Desktop on the publisher server and create a test app with the server based DSN to load data from Tera? This should help identify the problem.

[#5]

THAT appears to created progress.

I installed the client on the publisher, created a new report with the ODBC 32b connection and able to generate a basic table of a few fields pulled in.

Go back to the QMC and ran the task, it went through but with warnings.  The file was ditributed as wanted.

Just have to figure out wihat's generating these warnings.

------------------------

1/14/2015 12:32:50.9131919 Warning No recipients, skipping distribution of Reload of Richa Test.qvw_QVS_3
1/14/2015 12:32:50.9131919 Warning Distribution reported warnings for resource "Reload of Richa Test.qvw_QVS_3" (QlikViewServerDistributionResource). Warnings=1
1/14/2015 12:32:50.9131919 Warning Distribution to resources reported warnings. Warnings: 2

------------------------

Thank you for the help for progress Colin.

[Colin-Albert]

You should be able to copy the connect string from the test app to your original app.

[#7]

The original app ran flawless with a distribution folder.  The test app had a distribute to QV server location and a distribution folder which the QV Server location was bringing up the warnings.

I'm not as familiar how the distribute to server functions but other wise things are good.

Thank you for your help Colin.