Logging On Teradata Database Sessions via BTEQ

Tools
Tools covers the tools and utilities you use to work with Teradata and its supporting ecosystem. You'll find information on everything from the Teradata Eclipse plug-in to load/extract tools.
Teradata Employee

Logging On Teradata Database Sessions via BTEQ

When it comes to establishing Teradata Database sessions, you may find that using BTEQ’s LOGON command by itself is not sufficient to pass along your credentials for user authentication. This article will explain what other commands you might need to use.

This article’s purpose is to describe and illustrate the various ways one can establish Teradata Database sessions using all of the various command elements and settings that BTEQ provides. Its target audience is a first-time BTEQ user. Besides its LOGON command, Network-Attached (aka Workstation) BTEQ provides a number of other commands and settings that are for use in establishing sessions. Figuring out which of these to use for anything but the simplest of logons can be a challenge for a new BTEQ user. One must first determine which security mechanism must be employed. Then, the user must understand that the syntax for the chosen commands will vary depending on whether BTEQ is being used in interactive or batch mode.

The article’s focus is only on the specification of the attributes necessary to effect a logon. It does not cover how to instruct BTEQ to alter default session attributes such as transaction semantics and character set. All examples assume the default attributes are desired for the established sessions. If you are simply looking for a basic explanation about how to effect a logon, or need to get a fundamental understanding how to use BTEQ’s advanced logon settings -- such as those used in combination with external authentication mechanisms like LDAP -- then read on.

A fictitious user, “Jane Doe”, will be used to illustrate several prefabricated logon scenarios which collectively will require use of all the commands and settings. To keep within the scope of the topic, the running example used assumes Jane is a new BTEQ user that, although familiar with how to invoke BTEQ, needs to understand how to tell BTEQ to use the various authentication mechanisms that her DBA has already set up for her.

Logon Elements

The process of “logging on” via BTEQ is, at its simplest, triggered by issuing a LOGON command. This causes a request to get sent to the indicated Teradata Database for one or more sessions to get established in order that the specified user entity will then be able to submit SQL statements. For purposes of this article, the information needed for uniquely identifying the user as well as the database will be collectively referred to as the Basic Logon Elements. These are the attributes that, on their own, are generally sufficient for employing the simpler default authentication mechanism TD2, which most typically relies solely on provision of a LOGON command.

The four basic attributes are:

  • TDP Identifier
  • User Identifier
  • Password Value
  • Account Identifier

The more advanced forms of “logging on”, though, also require identification of a specific authentication mechanism such as LDAP or SSO. External authentication allows network attached users to be authenticated by an external agent rather than by a Teradata Database. You must properly configure the Teradata Database to support external authentication and must select a mechanism that supports it. Channel attached users cannot use external authentication.

The information needed for specifying which mechanism to use, as well as any argument data it might need, will be collectively referred to as the Advanced Logon Elements. Specifying information about which non-default mechanism to use requires use of BTEQ’s LOGMECH and LOGDATA commands.

The two advanced attributes are:

  • Mechanism Name
  • Mechanism Data

To handle a user’s LOGON request, BTEQ takes all of the basic and advanced elements and passes their information along to CLI. CLI will work with TeraGSS as needed to authenticate the user based on the user-specified or default security mechanism and then handles requesting the required connections. When the logon is successful, the Teradata Database will have assigned unique numbers to all the sessions associated with the logged on user. The following is a graphical representation of how the logon string and logon mechanism information gets routed for the purpose of authenticating a user. The logon elements are shown using their commonly used nicknames.

Flow of LOGON request

Basic Attributes

TDP Identifier

The TDP Identifier element, also known as TdpId value, identifies the target Teradata Database system which the user wants to log on to. The value can be comprised of any combination of letters and numbers. For Workstation BTEQ, up to 258 characters may be used in quoted or non-quoted form. For Mainframe BTEQ, only an assigned name string of up to 8 characters can be used. The term TdpId comes from the historical timeframe when BTEQ was first released and was only being built for execution via mainframe systems. Use of this term was carried over for all BTEQ build flavors, but is also referred to as “host name” or “database name”.

So for Mainframe BTEQ, the TdpId value actually identifies the assigned name of the Teradata Director Program or “TDP” client-side subsystem which will provide communication with the target database. A TDP establishes sessions with the Teradata Database and routes user requests between the client and the database. But for Workstation BTEQs, the TdpId is actually a value that must resolve down to an IP address corresponding to a server-side Teradata Gateway. The value given may represent a host name or an actual address -- using full internet IPv4 or IPv6 (as of TTU 13.10) formats.

These are the valid IPv4/IPv6 address formats supported by BTEQ:

  • <IPv4 address>
  • <IPv4 address>:<port number>
  • [<IPv6 address>]
  • [<IPv6 address>]:<port number>

And here are some examples of validly formatted Workstation BTEQ TdpId values expressed as addresses:

  • Internet format            --   mytdpid.td.teradata.com
  • IPv4 format with port   --   111.122.133.144:1025
  • IPv6 format                  --   [2002:9941:abcd::cebf]

What does this all mean for Jane? Well, what her DBA explained to her is that their company’s production Teradata Database system is called “tdprod” and their test system is called “tdtest”. The names were coined from the TdpId values used to logon sessions via network-attached BTEQ (meaning using Windows BTEQ or one of the supported UNIX or Linux BTEQs). She was told she shouldn’t need to quote the names or alternatively use any direct addressing formats since their DNS setup will enable CLI to lookup their necessary addresses by name. If she wants to use channel-attached BTEQ (aka z/OS BTEQ), however, she’s been told to use “TDPS” as the TdpId for tdprod and “TDTS” as the TdpId for tdtest.

User Identifier

The User Identifier value, also known as UserId, identifies the name of an existing user object to establish sessions for. Although BTEQ will accept (as of TTU 13.10) up to 2000 multi-byte characters for this value, the maximum allowed size is determined by the version of the Teradata Database system that was used to create the object name. The database also imposes rules about which characters can be used in the UserId value. The only rule imposed by BTEQ is that double quotes must surround a UserId value containing whitespace or comma characters.

So what is Jane’s UserId? Well, her DBA created three new user objects for her. One on tdtest called “Doe, Jane” and two on tdprod called “jd1” and “jd2”. The two tdprod users were created with different roles. The jd1 user would allow her to add new sales data and jd2 would allow her to access historical sales data. She was also told she would need to get into the habit of always quoting her UserId value for a logon to tdtest since it contains the comma and space characters.

Password Value

The Password value is a character string that must match the password string assigned to the associated UserId. The same object name format rules that apply to UserId values also apply to Password values. Double quotes may need to be used to enable BTEQ to correctly parse values supplied via LOGON command arguments.

So what are Jane’s Passwords? Well, her DBA created a default value of “sqlgood” for her tdtest UserId but told her she would instead be using her network password for authentication when logging on to tdprod.

Account Identifier

The Account Identifier value, also known as AcctId, is an optional quoted character string that associates the established sessions with an accounting group to enable their resource utilization to be monitored and/or prioritized. Like UserId and Password, AcctId values are subject to the database’s rules for object names. If not specified, a default account value associated with the user object will be used.

So what is Jane’s AcctId? Well, her DBA told her she can omit it entirely when logging on to tdtest. The default value of “pitstop” will be assumed. However, when she is going to be executing long-running queries on tdprod she should explicitly supply a value of “adhoc”.

Advanced Attributes

Mechanism Name

The Mechanism Name, also known as the LogMech value, identifies the name of the security mechanism which will need to define the security context under which the established sessions will operate. If not specified, the logon will proceed using the designated default mechanism. “NTLM”, “KRB5” and “LDAP” are all examples of valid LogMech values. The names are not case-sensitive and can be up to 8 characters in length.

When any value other than TD2 is supplied, the definition of the basic elements UserId and Password must be broadened as their values may then represent mapped user credentials managed not by a Teradata Database but rather by an external authentication mechanism. 

The values are still being used to determine which underlying Teradata Database user object to establish sessions for. But the user names may actually be different.

Jane’s DBA has informed her that she must use TD2 authentication (the out-of-box default) when accessing tdtest and must use LDAP (the site default) when accessing either of her tdprod UserIds.

Mechanism Data

Mechanism Data, also known as LogData, is a character string that is used to supply the non-Teradata-managed user credentials that are needed by the external authentication mechanisms being used.

This is where things become a bit more complex for Jane. Her DBA explained that since she has a choice of two UserIds on tdprod -- and has to use LDAP authentication to logon sessions using them -- that she would need to supply her network user credentials as well as qualify which tdprod UserId she wants to use via LogData when she logs on. The specific format she would need to use for the string would be as follows:

            <NetworkUserId>@@<NetworkPassword> user=<TeradataUserId>

Jane’s network user name is “JaneDoe” and her associated current password is “bulbs2flowers” reflecting her current penchant for gardening. So the string she would need to enter to logon to her tdprod jd1 UserId would need to be as follows:

            JaneDoe@@bulbs2flowers user=jd1

Commands & Settings

BTEQ provides several other logon-related commands besides LOGMECH, LOGDATA, and LOGON. These additional commands, which must be used prior to actually using the LOGON command (directly or tacitly), provide the ability to:

  • Establish multiple Teradata Database sessions
  • Make BTEQ’s interactive mode smarter
  • Make BTEQ’s LOGON command syntax shorter

New BTEQ users need to form the habit of always considering whether there will be a Teradata Database performance advantage to using multiple sessions with every logon they make. So although the scope for this article does not include how to request all the various types of sessions, it was decided that it should include how to request multiple sessions.

The last two actions are about taking measures to use the most efficient set of commands when logging on – whether interactively entering the necessary input or using a “pre-written” script.

SESSIONS Command

The SET SESSIONS command, also known as the SESSIONS setting, is used to assign an integer value for the number of sessions that all subsequent LOGON commands used should end up attempting to connect. It can not be used while already logged on. Note that the exact number of sessions being requested may not be available to get connected. As long as one session successfully gets established, BTEQ will treat the logon as successful.

Syntax:

SESSION command syntax diagram

The maximum number (n) is 200. BTEQ assumes 1 if the number argument is omitted.

The key for determining when to use multiple sessions lies in understanding that their existence may enable the Teradata Database to process requests in parallel. This might mean they could be useful for loading a large number of rows into a database when insert order is not important or when some of the associated SQL requests will be long running.

The SHOW CONTROLS command can be used to see what the current value is for the SESSIONS setting. For example, let’s assume Jane has invoked Windows BTEQ in order to interactively explore logon-related commands. She first uses the SET SESSIONS command to establish a persistent setting for having up to 5 sessions per logon and then follows that with a SESSIONS-specific SHOW CONTROLS command to verify she used the command correctly. The following snippet shows what output she would be seeing in the console window:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.set sessions 5

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.show controls sessions

 [SET] SESSIONS = 5

Note: To have cleaner examples, BTEQ’s ECHOREQ setting was set to OFF to produce most of the interactive output snippets in this article.

TDP Command

The SET TDP command, also known as the TDP setting, is used to override the default TdpId value to be used for all subsequent LOGON commands where a TdpId value is not supplied. Note that whenever a TdpId value is supplied as part of a LOGON command that the TDP setting is automatically updated with that value as the new default.

Syntax:

TDP command syntax diagram

Will Jane need to use this command? Well, her DBA told her that the Network-attached and Channel-attached CLIs that BTEQ will use have been configured to tell BTEQ to use tdprod and TDPS as the default TdpId values respectively. So she understands that in order to use tdtest that she is, at times, going to have to specify a TdpId value. It could be the case she develops habits using SET TDP that makes switching back and forth between tdprod and tdtest easier within the same BTEQ process. But, more likely, she will find that she prefers to use SET TDP when running RUN files or batch-driven scripts that contain pre-written LOGON statements and SQL requests which she does not want to have to alter as much to test them out on tdtest before running them on tdprod. Using Windows BTEQ interactively, here’s what Jane would see based on trying out the command and then using SHOW CONTROLS to verify the result:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.show controls tdp

 [SET] TDP = tdprod

 Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.set tdp tdtest

New TDP id: tdtest

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.show controls tdp

 [SET] TDP = tdtest

LOGONPROMPT Command

The Workstation-BTEQ-only SET LOGONPROMPT command, also known as the LOGONPROMPT setting, can be set to OFF or ON (its default). Setting it to OFF serves two purposes with regard to using external authentication mechanisms as follows:

  1. For logon scenarios where UserId and Password values do not actually need to be supplied, it is used to instruct BTEQ to purposefully suppress prompts and warnings that would normally occur for a user who incompletely supplies LOGON command arguments when using standard TD2 authentication when using BTEQ in interactive mode.  
  2. For interactive as well as batch modes, it allows use of the LOGON command to be treated as an optional action (rather than a required action) prior to submitting SQL. When OFF, BTEQ submits a tacit logon request to CLI when it encounters an SQL request being submitted to its input stream without any sessions having been first logged on.

Syntax:

LOGONPROMPT command syntax diagram

When would Jane need to use this command? Well, since she is going to use external authentication for her logons to tdprod, where she will be switching between using her jd1 and her jd2 UserIds, and she is going to be working in interactive mode sometimes, it’s quite likely that she will find she will want to tell BTEQ to suppress prompts associated with the LOGON command. Using Windows BTEQ interactively, here’s what Jane would see based on trying out the command and then using SHOW CONTROLS to verify the result:

 Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.set logonprompt off

*** Logon prompts disabled. Type .LOGONPROMPT ON; to re-enable.

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.show controls logonprompt

 [SET] LOGONPROMPT = OFF

Note that setting LOGONPROMPT to OFF is sometimes not going to be sufficient for suppressing all unnecessary prompts when using Windows BTEQ. You may also need to instruct CLI to suppress its generation of what is known as its GUILOGON dialog box.

This can be accomplished by setting the environment variable GUILOGON to NO.

LOGMECH Command

The Workstation-BTEQ-only LOGMECH command, also known as the LOGMECH setting, is used to supply the name of the needed authentication mechanism. Its use is only required when the default mechanism needs to be overridden.

Syntax:

LOGMECH command syntax diagram

Jane’s DBA told her that LDAP has been established at her site as the default mechanism for tdprod. When she wants to use the same BTEQ process to switch between logging on to tdprod and tdtest she will need to use this setting.

LOGDATA Command

The Workstation-BTEQ-only LOGDATA command, also known as the LOGDATA setting, is used to supply user credentials and qualifier parameters needed by the external authentication mechanism. BTEQ will accept a character string of up to 32000 bytes for the value.

Syntax:

LOGDATA command syntax diagram

For batch mode, the value is entered as an argument to the LOGDATA command on the same line of input with the string immediately following the LOGDATA keyword. However, since the LOGDATA value can contain sensitive information (such as a password), when the value is entered in interactive mode, the user must wait for BTEQ to switch to protected data-entry mode and give a prompt for the value to be entered. This protected mode entry exchange is also what BTEQ uses when prompting for a LOGON command’s Password value. Furthermore, the SHOW CONTROLS command can not be used to see what the current value is for the setting.

If you are entering a LOGDATA value interactively and forget to wait for BTEQ to prompt you for its protected mode entry, BTEQ will generate an error message. It took a few attempts for Jane to get into the correct habit. Using Windows BTEQ interactively, here’s what Jane saw when she “messed up”:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logdata JaneDoe@@bulbs2flowers user=jd1

*** Error: Value entered as argument, rather than as response to

            prompt.

And here’s what it looked like when she entered it correctly:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logdata

LOGDATA:

LOGON Command

The LOGON command, as mentioned previously, is what triggers the process of logging on. Its arguments are comprised of positional values for TdpId, UserId, Password, and AcctId elements or no argument string at all. In interactive mode, BTEQ will then prompt for any required missing values. What is considered to be “missing” will depend on the LOGONPROMPT, LOGMECH, and LOGDATA settings.

Syntax for Interactive Mode:

Interactive LOGON command syntax diagram

Syntax for Batch Mode:

Batch LOGON command syntax diagram

If the LOGMECH and LOGDATA commands were previously used for defining an external authentication mechanism and credentials, then the UserId and Password elements do not need to be included in the LOGON command.

So what happens when all values have been supplied without having to supply an argument string for the LOGON command **and** all logon prompts have been disabled? Well… BTEQ will proceed with doing a tacit logon for the user when it encounters a subsequent SQL request.

LOGON Examples

Jane is ready to logon and test out all of her Teradata UserIds for the first time. Her DBA helped her understand how to create scripts that can be executed using BTEQ’s RUN command. So for the moment she’s using batch mode logons, so as not to have to retype all the commands while figuring things out. Here’s the Windows BTEQ script that she initially comes up with:

  /*-------------------------------------------------------*/

  /* Logon 1 tdtest session using “Doe, Jane”.             */

  /*-------------------------------------------------------*/

  .SET TDP tdtest

  .LOGMECH TD2

  .SET SESSIONS 1

  .LOGON tdtest/”Doe, Jane”,sqlgood,’pitstop’;

  SELECT USER;

  .LOGOFF;

  /*-------------------------------------------------------*/

  /* Logon 1 tdprod session using jd1 for pitstop queries. */

  /*-------------------------------------------------------*/

  .SET TDP tdprod

  .LOGMECH LDAP

  .LOGDATA JaneDoe@@bulbs2flowers user=jd1

  .SET SESSIONS 1

  .LOGON tdprod/,,’pitstop’;

  SELECT USER;

  .LOGOFF;

  /*-------------------------------------------------------*/

  /* Logon 5 tdprod sessions using jd2 for adhoc queries.  */

  /*-------------------------------------------------------*/

  .SET TDP tdprod

  .LOGMECH LDAP

  .LOGDATA JaneDoe@@bulbs2flowers user=jd2

  .SET SESSIONS 5

  .LOGON tdprod/,,’adhoc’;

  SELECT USER;

  .LOGOFF;

Everything worked fine. However, she didn’t need to explicitly specify all values for every setting used for each LOGON. It could be greatly condensed for these reasons:

  • Using the SET TDP command upfront means she doesn’t need to supply a TdpId value for the LOGON commands.
  • Once TDP is set to tdprod it doesn’t need to be reset for the logon to her jd2 UserId.
  • Once LOGMECH is set, its value will persist so it doesn’t need to be reset for the second LDAP logon.
  • The initial default SESSIONS setting is 1. So it doesn’t need to be changed until 5 sessions are to be requested.
  • Since ‘pitstop’ is her default AcctId, she does not need to specify it at all.
  • There would be no need to use a LOGON command for the second logon since she could let her AcctId value default and has supplied all other values through persistent settings. However, she would have had to issue a LOGONPROMPT OFF command to be able to do that which doesn’t make sense for the batch mode context. So using the LOGON command actually makes her script easier to understand.

So here’s all she really needed in her script:

  /*-------------------------------------------------------*/

  /* Logon 1 tdtest session using “Doe, Jane”.             */

  /*-------------------------------------------------------*/

  .SET TDP tdtest

  .LOGMECH TD2

  .LOGON ”Doe, Jane”,sqlgood;

  SELECT USER;

  .LOGOFF;

  /*-------------------------------------------------------*/

  /* Logon 1 tdprod session using jd1 for pitstop queries. */

  /*-------------------------------------------------------*/

  .SET TDP tdprod

  .LOGMECH LDAP

  .LOGDATA JaneDoe@@bulbs2flowers user=jd1

  .LOGON

  SELECT USER;

  .LOGOFF;

  /*-------------------------------------------------------*/

  /* Logon 5 tdprod sessions using jd2 for adhoc queries.  */

  /*-------------------------------------------------------*/

  .LOGDATA JaneDoe@@bulbs2flowers user=jd2

  .SET SESSIONS 5

  .LOGON tdprod/,,’adhoc’;

  SELECT USER;

  .LOGOFF;

As a final exercise, Jane decided to explore completely interactive logons using Windows BTEQ. First she wanted to logon to tdtest and then tdprod. Remembering that she needed to override the default TdpId value of “tdprod” supplied by CLI, she entered the LOGON command including the TdpId value followed by a slash character. She was immediately prompted for her UserId value…

 Teradata BTEQ 13.10.00.00 for WIN32.

Copyright 1984-2010, Teradata Corporation. ALL RIGHTS RESERVED.

Enter your logon or BTEQ command:

.logon tdtest/

.logon

UserId:

After entering “Doe, Jane” (including double quotes), she was then prompted to enter a Password value…

Password:

She went ahead and entered her “sqlgood” password and noticed she was not subsequently prompted to enter an AcctId default but the logon succeeded and BTEQ generated success messages that looked similar to this…

*** Logon successfully completed.

*** Teradata Database Release is 13.10.00.00

*** Teradata Database Version is 13.10.00.00

*** Transaction Semantics are BTET.

*** Session Character Set Name is 'ASCII'.

She decided to move on to logging on interactively using her jd2 tdprod user. This time she wanted to specify her AcctId as “adhoc”. So how would BTEQ prompt her for the AcctId value? Well, what was not so obvious before was that she would have needed to enter both her Password as well as her quoted AcctId, separated by a comma, at the Password prompt for her tdtest logon. To make matters more confusing, this time, since she would be using LOGDATA to authenticate to tdprod, she didn’t need to enter her Teradata UserId/Password values for the LOGON command and in fact would be first setting LOGONPROMPT to OFF to suppress prompts. After reviewing her batch mode logon script, she figured out she would just need to include it on the LOGON command rather than be prompted for it. The sequence of commands she used was… LOGONPROMPT, LOGMECH, LOGDATA (for which she had to blindly enter in her credentials), and then LOGON. Here’s what her console window output looked like…

 Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logonprompt off

*** Logon prompts disabled. Type .LOGONPROMPT ON; to re-enable.

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logmech ldap

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logdata

LOGDATA:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:

.logon tdprod/,,'adhoc';

.logon tdprod/,

 *** Logon successfully completed.

*** Teradata Database Release is 13.10.00.00

*** Teradata Database Version is 13.10.00.00

*** Transaction Semantics are BTET.

*** Session Character Set Name is 'ASCII'.

Ah… sweet success. We can now say bon voyage to Jane. smiley

Concluding Remarks

Hopefully reading through this article has given you a better understanding of the basics of how to use BTEQ to logon Teradata Database sessions. The goal was to cover all associated commands and settings and to provide some simplistic examples of the more complex scenarios in order to give an idea of the BTEQ-specific issues that might be encountered. As such, the scope of this article was very narrow and confined to BTEQ itself. There is much more to know about when it comes to connecting to the Teradata Database and many related topics that might be of further interest to you. Just to name a few, you may want to find out :

  1. What special characters the database allows for logon object names.
  2. Which command to use to set environment variables recognized by CLI.
  3. How to configure a specific authentication mechanism.
  4. How to create a user that has a STARTUP string.
  5. How to establish the same query band across multiple sessions.
  6. How to use UTF8 or UTF16 as a session character set.

Obviously, the list could go on and on. To learn more about BTEQ itself, go through the Basic Teradata Query Reference Manual (Publication B035-2414). If you are further interested to know about the logon mechanisms, go through the Teradata Database Security Administration manual (Publication B035-1100). And to know more about CLI SPB defaults, such as TDP Id and session character set, go through the Teradata Call-Level Interface Version 2 reference manuals (Publications B035-2417 and B035-2418).

15 REPLIES
Enthusiast

Re: Logging On Teradata Database Sessions via BTEQ

how to use windows credential to logon (assuming kerbros setup is done in DBS)
Enthusiast

Re: Logging On Teradata Database Sessions via BTEQ

Great article! I've been wondering about how to log on interactively for a good while now, so I can play around with different Teradata extensions and formats. Thanks a lot!
Teradata Employee

Re: Logging On Teradata Database Sessions via BTEQ

Windows credential to logon for KRB5 mechanism is similar to LDAP mechanism
Enthusiast

Re: Logging On Teradata Database Sessions via BTEQ

This is extremely well documented, thanks. The only issue I am having is figuring out what to type in interactive mode for LOGDATA:? In the write up, it does not say what to enter interactively. When I try it, I keep getting errors, but it works fine in a script. You wrote:

And here’s what it looked like when she entered it correctly:

Teradata BTEQ 13.10.00.00 for WIN32. Enter your logon or BTEQ command:
.logdata

LOGDATA:

But what do we enter here because when I enter what I think, it gives me the following error:

Password:

*** CLI error: MTDP: EM_SSOLOGONFAIL(244): SSO logon failed by gateway.
*** Return code from CLI is: 244
*** Error: Logon failed!

Thanks
Teradata Employee

Re: Logging On Teradata Database Sessions via BTEQ

SSavoye,

Thanks for your comment. Support has been contacted and is investigating the issue.
Enthusiast

Re: Logging On Teradata Database Sessions via BTEQ

Hello,

UserID on dbc.DBQLogTbl table is seems to be something in hexdecimal format like '00-00-75-0F' . Can you please tell me how can I derive the actual logon userid and/or viceversa.

Regards,
Ayush Jain
Enthusiast

Re: Logging On Teradata Database Sessions via BTEQ

dbc.dbase databaseid

dbqlogtbl contains actual user name and user id..
help table dbc.dbqlogtbl;
Fan

Re: Logging On Teradata Database Sessions via BTEQ

Hi nice article,
How about ssavoye problem? I have similar problem with CLI error: MTDP: EM_SSOLOGONFAIL(244): SSO logon failed by gateway. I'm using LDAP simple binding and have changed LdapServerRealm with the full DNS name also.
Teradata Employee

Re: Logging On Teradata Database Sessions via BTEQ

Qbuck,

Thanks for the post. This is an issue that we have been looking to reproduce. We believe the problem may be that the environment variables may be set improperly when running BTEQ interactively. Please contact me so we can help troubleshoot the problem.