I'm used to having to trap for run-time issues when trying to connect to databases. In Oracle, if I fat-finger a password and try to use it to connect, I'd get a run-time error with an Exception.Number value of 1017. There doesn't seem to be like procedure in Teredata even though I find references to an 8017 run-time error somewhere (in the Message to be sure but I'd rather not have to parse that).
What is the recommended method of trapping invalid userID/password attempts at connecting to a Teradata database?
Thanks in advance.
You always get a "Failure 8017 The UserId, Password or Account is invalid.", it's just not telling you exactly what was wrong.
Maybe your client suppresses this error?
Yes, the Teradata Gateway returns the generic 8017 error code in case of any logon failures and this masking of the underlying error is needed for security reasons. If I understand your question, you are trying to get the underlying reason for the logon failure (for example bad password or non-existent user and etc.) for logon failures? Are there any issues trapping 8017 error and treat it as a logon failure?
Using the Teradata .NET ADO Provider. When attempting to open a connection and I've supplied an incorrect user ID or password, an exception occurs. I can trap that in a Try...Case...End Try structure. When it catches the error, the TdException.ErrorCode is not 8017. The closest condition I can find to detect credential failure like this is to look for Errors(0).Number. Why doesn't it just return 8017?
TdException.ErrorCode is defined to be a Microsoft-compatible HRESULT. TdException returns an Errors collection of TdError instances (because in some cases there can be more than one error, e.g. propagated from different levels in the API stack) and the Teradata error Number can be found there - typically in the first occurrence, as you note.