Loading…
Archives of the TeradataForum
Message Posted: Mon, 23 Jul 2012 @ 22:29:26 GMT
 |
 |
|||||||
| <Prev | Next> | <<First | <Prev | Next> | Last>> |
| Subj: | Re: Error — 3149:TDWM Filter violation for Query Request | |
| From: | Barrow, Martin |
You need to speak to your DBA. A filter is in place in the workload management (TDWM) that is preventing your query from running. The filter
is called —
> 'Unrestrained PJ - Max Row Count'
The filters can be set up to check the request before it runs and stop it running based on a set criteria. You need to find out from the
DBA what the filter checks are.
|
|
|||||||
| <Prev | Next> | <<First | <Prev | Next> | Last>> |
- Remove From My Forums
-
Question
-
I have just installed MS SQL Server Express on my Laptop. In the install, I told it to use windows authentication. I didn’t put a password to the user (it was grayed out), but I do have a password in my startup of the laptop.
I use a Development App that uses an ODBC connection to access the SQL Server’s DBs. When I set up the ODBC DSN, it didn’t need a username or password. I tested it and it stated «Successful».
In my development app, I try to connect to the ODBC and it will not connect giving a «IDispatch error #3149» error. No matter if I use my windows login/password or anything else…it will not connect and it gives the error.
What do I do?
Thanks,
Joe
Answers
-
Hello Joeah,
I think that that , when you have «Provider=SQLOLDDB» in your connection string (your 3rd post), you are using the OLEDB driver, not the ODBC driver, so your are not using your ODBC DSN.
For your question «connecting with Windows authentification» it is simple : as soon as you use the keywords UId and Pwd, you are using the SQL Server authentification.If You don’t use the Pwd and UId keywords and you use «Trusted_Connection=True;» , you are
using the Windows Authentification ( that’s to say the Windows Login used when your computer started.
You should try the connection string proposed by Kuldeep as it is a good way to check whether you can connect to your server ( and its syntax is correct ).
In your last connection string
«Provider=SQLOLDDB;Server-JMAH-PCSQLEXPRESS;Uid=JMAH;Pwd=;»
you have another possible error between Server and JMAH , you should have a = not a —
You have an excellent site to help you to build a connectionstring :
http://connectionstrings.com/
http://connectionstrings.com/sql-server-2008
http://connectionstrings.com/sql-server-2008#p3
the last link is for ODBC
Please, could you provide the version version of your SQL Server ( 2005,2008,2008 R2) ? It is a value always important to provide.
Also, please, could you tell us why you are using the ODBC driver ? in an application or in a SQL Server program ( SQLCMD, SQL Server Management Studio Express , the last one is often shortened as SSMSE )
We are waiting for your feedback to try to help you more efficientlyHave a nice day
Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
-
Marked as answer by
Sunday, October 16, 2011 7:53 PM
-
Marked as answer by
- Remove From My Forums
-
Question
-
I have c++ application which USES ADO to connect to SQL server. Its able to connect to a database(aa_login) in one server(Lets say Server01). When I try the same code in another server(Server02) to connect to a database it fails and
gives the Following error«IDISPATCH error #3149, Login failed for user ‘sa’ «.
Could there be any problem with that server registry. Can someone please help me.
All replies
-
Can you login into the database where connection is failing via other login or SA using SSMS ?. Can you check SQl Server errorlog there should be more information about why actually the login failed.
Cheers,
Shashank
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My TechNet Wiki Articles
MVP
Advanced Troubleshooting
Review log files to identify the issue
To investigate why SQL log truncation has failed, the Veeam logs will need to be reviewed to determine which part of the truncation procedure failed.
For Veeam Backup & Replication, the log file containing information about the truncation procedure will be found on the SQL server, and is named:
C:ProgramDataVeeamBackupVeeamGuestHelper_ddmmyyyy.log
Within the VeeamGuestHelper log file, beneath the line «Transaction log truncation statistics,» you will see information about which account was used, which SQL instances were processed, and a list of each database that was interacted with.
VeeamGuestHelper Log Example
In this example, the account domainbkpadmin does not have permissions within the SQL Instance.
For Veeam Agent for Microsoft Windows, the log file containing truncation details will be found on the SQL server in:
C:ProgramDataVeeamEndpoint<jobname>Job.Backup.log
Within the Job.Backup.log log file, beneath the line «Checking if can truncate SQL logs.» you will see information about which account was used, which SQL instances were processed, and a list of each database that was interacted with.
Job.Backup.log Example
In this example, the account domainbkpadmin does not have permissions within the SQL Instance.
Known Errors and Solutions
Below is a list of commonly observed errors found in the logs and solutions to each.
The user listed in the error cannot connect to the SQL Instance, as it does not have the required SQL permissions.
This specific error means that the account in the error isn’t listed in the «Logins» section of the SQL Instance, and therefore has no right to login to the SQL Instance. To resolve this, create a login for the account within the SQL Instance on the machine that is failing to truncate, and assign it the sysadmin role.
Note: You will need to launch SQL Management Studio using an account other than the one in the error, as that account will not have permission to connect to the SQL Instance.
The user listed in the error is able to log in to the SQL Instance but lacks the required SQL permissions to interact with the databases.
To resolve this, connect to the SQL Instance of the machine that is failing to truncate, and edit the login entry ( Security > Logins ), and assign the sysadmin role.
Note: You will need to launch SQL Management Studio using an account other than the one in the error, as that account will not have sufficient permissions to assign itself the sysadmin role.
This issue is often seen on the secondary node of a SQL Server AlwaysOn cluster. This issue can be solved by manually creating a backup of the database mentioned in the error using SQL Server Management Studio. Alternatively, you can set the secondary node as primary for just one backup job run. As a result, all databases on that node will be backed up without the «copy only» flag, and the error will dissipate.
The issue occurs when the secondary node has always been backed up with the «copy only» flag, and its standalone DBs do not have a full backup. Thus during the truncation of the standalone DB logs, this error occurs.
The same solution applies if you get this message about the excluded vCenter or Veeam database.
This message means that the truncation process could not be completed within the default execution timeout.
It is possible to increase the execution timeout. However, the registry value and placement depend on the SQL backup job’s configuration. See below:
For a VM being backed up by Veeam Backup & Replication
The following registry value can be created on the SQL server having the issue and adjusted to change the SQL task execution timeout (default 300 seconds).
Key Location: HKLMSOFTWAREVeeamVeeam Backup and Replication
Value Name: SqlExecTimeout
Value Type: DWORD (32-Bit) Value
Default Value Data: 300 (Decimal)
The value is in seconds. Increase the value and rerun the job. The value needed will be unique to each environment.
A common tactic is to increase the value by 300, test the job, and increase by another 300 seconds if it fails.
For a machine backed up using Veeam Agent for Microsoft Windows *except Failover Cluster job type
This registry value may be used for all jobs involving Veeam Agent for Microsoft Windows, except Failover Cluster type jobs.
The following registry value can be created on the SQL server having the issue and adjusted to change the SQL task execution timeout (default 300 seconds).
Key Location: HKLMSOFTWAREVeeamVeeam Endpoint Backup
Value Name: SqlExecTimeout
Value Type: DWORD (32-Bit) Value
Default Value Data: 300 (Decimal)
The value is in seconds. Increase the value and rerun the job. The value needed will be unique to each environment.
A common tactic is to increase the value by 300, test the job, and increase by another 300 seconds if it fails.
For a SQL Failover Cluster that is backed up using Failover Cluster job within Veeam Backup & Replication
This scenario is specific to when a Veeam Agent for Microsoft Windows backup is managed by Veeam Backup & Replication, and the Job Mode is set to Failover cluster type.
To implement this SQL task execution timeout, the following registry value must be created on all nodes of the SQL Failover cluster.
Key Location: HKLMSOFTWAREVeeamVeeam Backup and Replication
Value Name: SqlExecTimeout
Value Type: DWORD (32-Bit) Value
Default Value Data: 300 (Decimal)
The value is in seconds. Increase the value and rerun the job. The value needed will be unique to each environment.
A common tactic is to increase the value by 300, test the job, and increase it by another 300 seconds if it fails.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
I have created a new backup job in Veeam Backup & Replication that contains a VM running Microsoft SQL server. I have enabled application-aware processing. However, the job completes with the following warning:
Unable to truncate Microsoft SQL Server transaction logs. Details: Failed to process ‘TruncateSQLLog’ command. Failed to truncate SQL server transaction logs for instances: SHAREPOINT. See guest helper log.
Having reviewed the guest helper log, which is stored in C:ProgramDataVeeamBackup on the VM, it is clear that the service account used by the backup job does not have access to the SQL databases:
INFO RPC: truncation SQL logs.
Job UID: '{759cbd3e-efca-4ca3-b0cc-611954bc864f}'.
Login: webbworldveeam_serv
Enumerating SQL instances
Enumerating Microsoft SQL Server instances by service names.
SQL instance found: [SHAREPOINT]
Enumerating Microsoft SQL Server instances by service names.. Ok.
Truncating database logs (SQL instance: SHAREPOINT). User: webbworldveeam_serv.
Using default SQL provider 'sqloledb' to connect to SQL server
INFO Connecting to mssql, connection string: Provider='sqloledb';Data Source='(local)SHAREPOINT';Integrated Security='SSPI';Persist Security Info=False, timeout: 15
Code = 0x80040e4d
Code meaning = IDispatch error #3149
Source = Microsoft OLE DB Provider for SQL Server
Description = Login failed for user 'WEBBWORLDVeeam_Serv'.
COM error: Code: 0x80040e4d
The solution was to grant the service account used by the backup job ‘DB_BackupOperator’ rights on each of the databases being backed up. Now the job completes successfully.
IPSwitch Whats up gold v 11 was installed via the attached instructions. However when i try to use the webconsole to start discovering devices or try to go directly into the whatsupgold management console i receive the following error:
«Database connection error.
Error=80040E4D
ErrorMessage=IDispatch error #3149
Description=[Microsoft][ODBC SQL Server Driver][SQL Server]Login Failed for user «(null)’. Reason: Not associated with a trusted SQL server Connection.
7-24-2009-2-39-02-PM.jpg
Dell-025-WhatsUP-Gold.pdf
Network ManagementMicrosoft SQL Server 2005
BTEQ Return Codes:
Bteq return codes are the two digit values that BTEQ returns to the client operating system as a result of any error code occured in BTEQ session. Possible BTEQ return codes are as given below
Return Code Description
00 Job completed with no errors.
02 User alert to log on to the Teradata Database.
04 Warning error.
08 User error.
12 Severe internal error
The return code is decided by the Error messages that BTEQ receives from the Teradata database. Different Teradata database error codes are assigned a specific return code value.
The below table will give what different return codes are returned by BTEQ for different Error codes it receives from Teradata database.
For an Example : If you issue a SQL statement in BTEQ session to create a table which is alrady there, then Teradata database will return an error code of 3803 to the BTEQ session and in turn in BTEQ will send a return code of 04 to the client operating system where you have intiated the BTEQ session.
Return Code = 04 ( BTEQ returns a return code of 04 for the following Teradata error codes )
2580 — Mload not active on table %TVMID.
2667 — Statistics cannot be collected on an empty table.
3534 — Index already exists.
3666 — This view has too many columns to store or retrieve comments.
3737 — Name is longer than 30 characters.
3747- No start-up string defined for this user.
3803 — Table “%VSTR” already exists.
3804 — View “%VSTR” already exists.
3805 — Macro “%VSTR” already exists.
Return Code = 08 ( BTEQ returns a return code of 04 for the following Teradata error codes )
CLI0530 -Character set name or code unknown.
2123- A segment could not be read successfully.
2538 -A disk read error occurred in the tables area.
2541- End of hash code range reached.
2632- All AMPs own sessions for this Fast/MultiLoad
2639 — Too many simultaneous transactions.
2641 %DBID.%TVMID was restructured. Resubmit.
2644 No more room in database %DBID.
2654 Operation not allowed: %DBID.%TVMID is being restored.
2805 Maximum row length exceeded in %TVMID.
2809 Invalid recovery sequence detected.
2815 Apparent invalid restart of a restore.
2818 Invalid lock to dump table without after image journaling.
2825 No record of the last request was found after Teradata Database restart.
2826 Request completed but all output was lost due to Teradata Database restart.
2827 Request was aborted by user or due to statement error.
2828 Request was rolled back during system recovery.
2830 Unique secondary index must be dropped before restoring table.
2835 A unique index has been invalidated. Resubmit request.
2837 Table being fast loaded; no data dumped.
2838 Table is unhashed; no data dumped.
2840 Data rows discarded due to inconsistent hash codes.
2843 No more room in data base.
2866 Table was recovery aborted; no data dumped.
2868 This permanent journal table is damaged; no data dumped.
2920 Delete journal and AMP down without dual.
2921 No saved subtable for journal %DBID.%TVMID.
2926 No more room in %DBID.%TVMID.
3001 Session is already logged on.
3111 The dispatcher has timed out the transaction.
3116 Response buffer size is insufficient to hold one record.
3119 Continue request submitted but no response to return.
3120 The request is aborted because of a Teradata Database recovery.
3523 %FSTR does not have %VSTR access to %DBID.%TVMID.
3524 %FSTR does not have %VSTR access to data base %DBID.
3566 Data base does not have a PERMANENT journal.
3596 RESTORE Teradata Database invalid if table, view or macro exists outside of
Teradata Database.
3598 Concurrent change conflict on data base; try again.
3603 Concurrent change conflict on table; try again.
3613 Dump/restore, no hashed nonfallback tables found.
3656 Journal table specified no longer exists.
3658 ROLLBACK/ROLLFORWARD table specifications are invalid.
3705 Teradata SQL request is longer than the Simulator maximum.
3802 Database “%VSTR” does not exist.
3807 Table/view “%VSTR” does not exist.
3824 Macro “%VSTR” does not exist.
3873 “%VSTR” is not a journal table.
3877 NO FALLBACK specified and the table is FALLBACK.
3897 Request aborted due to Teradata Database restart. Resubmit.
3916 Requested information not in dictionary.
5495 Stored Procedure %VSTR does not exist.
Return Code = 12 ( BTEQ returns a return code of 04 for the following Teradata error codes )
CLI0001 Parameter list invalid or missing.
CLI0002 Invalid number of parameters received.
CLI0003 Error validating HSIRCB.
CLI0004 Error validating HSICB.
CLI0005 Error validating HSISPB.
CLI0006 Invalid destination HSICB detected.
CLI0007 Invalid destination RCB detected.
CLI0008 DBCFRC unable to free RCB/HSICB control blocks because they are not
contiguous in storage.
CLI0009 Invalid DBCAREA pointer or id.
CLI0010 ECB already waiting.
2971 The AMP lock table has overflowed.
2972 No table header exists for table.
How to handle Errors :
BTEQ alos maintains the return code value in an internal Atrribute called ERRORLEVEL which you can later test and take necessary action depending upon the return code.
For any database error message which is not given above, BTEQ assigns a default return code of 8 to it. Also there is a way to specify a different return code to it.
. SET ERRORLEVEL UNKNOWN SEVERITY N
This BTEQ return codes can be used to Test and Branch accordingly
For an example.
SELECT * FROM TABLE1;
.IF ERRORLEVEL >= 14 THEN .QUIT 17
Also we can change the severity level of different error codes.
example :
.SET ERRORLEVEL 2168 SEVERITY 4
(2173,3342,5262 ) SEVERITY 8
.SET ERRORLEVEL UNKNOWN SEVERITY 14
BTEQ error level severity has no immediate impact on operations unless the error checking is incorporated in the scripts. The MAXERROR attribute sets threshhold value. So if any error occurs for which the return codes in greater than the MAXERROR the scripts terminates.
.SET MAXERROR 12
Note :
If you do not specify a MAXERROR value, BTEQ jobs execute until one of the following
conditions occurs:
• End-of-file for the primary command input file is encountered.
• A QUIT command is processed.
• A fatal error is detected.
• When BTEQ receives an I/O abend, system error messages either appear in the MVS
JES job log or are displayed on the CMS terminal.
• When BTEQ receives an I/O error or an abend, the SAS/C runtime library produces an
LSCX message that may provide more information about the error.
For more information on I/O errors and abends, refer to “I/O Errors and Abends”
Problem
When trying to login into iBase or Designer, there is a login failure for a userid different than the id used to login when trying to open an upsized ibase database. The details shows the following:
Login failed for user 'xxxxxxx'. [ Details << ] Error #3149 occurred in: Microsoft OLE DB Provider for SQL Server idDBEngine:mGetADOConnection idDBEngine:Connect idDBConnection:Connect idDBSystem:OpenDB idDBSystem:OpenDatabase FMain:DoCommand FMain:DoCommand(DatabaseOpen)
Cause
In the iBase Configuration of the upsized iBase database, the SQL Server connection id used for the iBase server to connection to the SQL Server database has a password which has not been updated after the change of the password in the SQL Server Security.
Resolving The Problem
Launch the iBase Database Configuration utility from the Windows Start Programs list under IBM i2 iBase 8.
Identify your Security file (.ids) and your iBase database file (.idb) and specify an iBase admin user such as SYSADMIN.
Here’s an example:
In the next screen you will see the SQL Server id used to connect to your ibase database. This is where you need to update the password of the SQL connection id:
Save the updated password with the checked option to «Test connection before saving». If the connection succeeds then you should now be able to connect using iBase and Designer.
Document Location
Worldwide
[{«Business Unit»:{«code»:»BU059″,»label»:»IBM Software w\/o TPS»},»Product»:{«code»:»SSXW43″,»label»:»i2 iBase»},»Component»:»Designer;iBase»,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»»,»Edition»:»»,»Line of Business»:{«code»:»LOB24″,»label»:»Security Software»}}]
Historical Number
TS002285421
Product Synonym
ibase; designer