I am using DB2 receive location in BizTalk 2016 configured with select query in SQL Command field. When I try to enable the receive location, I am getting the below error message.
The adapter "DB2" raised an error message. Details "There was an error in the Receive location with URI: DB2://XXXX:XX/XX/XXX. Internal message: Couldn't parse object name from polling statement".
I came to know that problem is with CASE statement inside query statement. When I remove CASE statement, it is working as expected. But the same query including CASE statement is working in BTS 2013 R2.
I tried installing latest cumulative updates for both BizTalk and HIS i.e., BizTalk 2016 CU7 and HIS 2016 CU3 and still the issue is not resolved. Can any one suggest the resolution or fix available for this?
Move your query to a stored procedure, and have the adapter poll that.
Related
I'm trying to watch trace events on SQL Server 2019 and created an Extended Events session like this:
CREATE EVENT SESSION [test] ON SERVER
ADD EVENT sqlsni.trace
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
However, the started session doesn't return anything when watching Live Data.
On an SQL Server 2017 the exact same thing returns data as expected.
On both SQL servers I'm using the SA account
I also tried adding a file target. But the file target also remains empty...
Is there anything in SQL Server that needs to get enabled? Any other reason for this not to work?
Try
ADD EVENT sqlsni.sni_trace
We are having an issue with SQL Server 2008 R2 64 responding to stored procedure call. About every 2 weeks or so, the database stops responding to stored procedures called from an ADO connection/Command set (4.0 framework). We have been working on this for several months now, with little improvement.
System changes:
We upgraded an existing vendor product from SQL Server 2005 to SQL Server 2008 R2 via their upgrade method. The database instance moved from a 32-bit Windows 2003 Server to 64-bit Windows 2008 Server.
The pattern of failure:
The application is run throughout the day, executed by different users via Citrix without issue. Every few weeks, the application stops responding around the same time frame. Once the database stops responding to the hosted instance of the application, any execution of the procedure from the application hangs (installed on CITRIX server, installed on varied physical systems, or debugging in VStudio 2010). After an hour of checking logs, server status, SQL Monitoring tools, tracing the repeated execution attempts, the server decides to respond to the application without intervention.
Strange thing is, when the server is not responding to ADO.Net calls, we execute the stored procedure from SQL Server Management Studio and receive results in 1 to 2 seconds. We are using the same login to access SQL Server Management Studio, and executing the stored procedure with the same parameters.
Looking at the connection string passed to the ADO connection, I don’t see anything unusual:
connectionString="Data Source=myserver\myinstance;Initial Catalog=databaseName;Persist Security Info=True;User ID=xxxxx;Password=yyyyy;Connect Timeout=45"
Tried so far:
Added extra 2gb of RAM to the OS: no change
Added extra tempdb file, expanded size of tempdb log file from 1 to 5gb: reduced the issue from weekly to every 2nd or 3rd week.
Installed SQL Server 2008 R2 SP3: no change.
The black cloud:
To me, the repeating time pattern of failure implies an issue at the database host (server or resource), but the DBAs do not see load or resource issue. If it were purely a host issue, why does it respond to SQL Server Management calls, and not ADO.NET calls?
The last occurrence lasted over two hours, and was resolved after rebooting the database server. Not a great fallback, but desperate times and all…..
Updating the ADO.NET connection to use named pipes has resolved the issue for our application. Prefixing the database name with "np:" has the connection using named pipes.
connectionString="Data Source=np:myserver\myinstance;Initial Catalog=databaseName;Persist Security Info=True;User ID=xxxxx;Password=yyyyy;Connect Timeout=45"
The issue returned on 5/14. This query timeout posting gave us hints how to force SQL Management Studio to behave like the ADO.NET connection and allowed us to recognize this is a "parameter sniffing" issue. We have applied changes to disable the parameter sniffing within the stored procedure.
RAISEERROR not supported in SQL Server 2012
RAISERROR 44444 'Field ''CostCodeId'' cannot contain a null value.'
How to change the syntax to make it to support in sql server 2012. Any alternative please help.
In SQL 2012 you should use THROW.
Here is link New THROW statement in SQL Server 2012
For any new development work start using THROW, and if possible start replacing RAISERROR with THROW, as it can be replaced anytime in future (but I don't think in near future).
RAISERROR was deprecated in SQL Server 2012 and replaced by THROW, and it may be completely replaced by THROW in new versions of SQL Server.
With RAISERROR it was mandatory to provide the parameters like error_message, error_number, error+severity, but with THROW all there are optional. THROW gets all this information from the new and improved error handling mechanism and returns the information to the user in case of any exception.
I am using Tableau version 8.0.0. When i publish the report in Live server i get the following error **"TableauException: Field '[ACCOUNT_SCHEDULE_FACT].[DATE_DM]', which is included in a join clause, does not exist. Unable to connect to the server ". I have verified that the column DATE_DM exists in the table ACCOUNT_SCHEDULE_FACT. The server is up and running. The join condition in the report has been verified even for case sensitive issue.
However when i publish the same report in Development Server or when i check it in desktop (without publishing) it does not throw any error and works smoothly. The custom sql from tableau has been executed in our sql server database and it returns correct number of rows. Can somebody point out why this error is occurring or whether there is any workaround for this problem?
Thanks and regards
Gautam
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.