In our production database there is an sp which was working fine till 2nd Nov 2014 and suddenly it started giving warnings that is
Warning : Null value is eliminated by an aggregate or other SET operation because we Ansi_warning ON in our Production database
so to resolve it we had marked as set Ansi_warning OFF in the beginning sp
So can anybody tell me is there any way I can check when was the last time or by whom Ansi_warning was set
You can see all your configuration changes by using this t-sql
DECLARE #sTracePath VARCHAR(1024)
SELECT #sTracePath=CONVERT(VARCHAR(500),value) FROM fn_trace_getinfo(DEFAULT)
WHERE property=2
SELECT TEXTData,HostName,ApplicationName,DatabaseName,LoginName,SPID,StartTime,EventSequence
FROM fn_trace_gettable(#sTracePath,1)
WHERE TEXTData LIKE '%configure%' AND SPID<>##spid
ORDER BY StartTime DESC
This of cource is based on that you have default trace enabled on the server.
Related
So I have a stored procedure in SQL Server. I've simplified its code (for this question) to just this:
CREATE PROCEDURE dbo.DimensionLookup as
BEGIN
select DimensionID, DimensionField from DimensionTable
inner join Reference on Reference.ID = DimensionTable.ReferenceID
END
In SSIS on SQL Server 2012, I have a Lookup component with the following source command:
EXECUTE dbo.DimensionLookup WITH RESULT SETS (
(DimensionID int, DimensionField nvarchar(700) )
)
When I run this procedure in Preview mode in BIDS, it returns the two columns correctly. When I run the package in BIDS, it runs correctly.
But when I deploy it out to the SSIS catalog (the same server the database is on), point it to the same data sources, etc. - it fails with the message:
EXECUTE statement failed because its WITH RESULT SETS clause specified 2 column(s) for result set number 1, but the statement sent
3 column(s) at run time.
Steps Tried So Far:
Adding a third column to the result set - I get a different error, VS_NEEDSNEWMETADATA - which makes sense, kind of proof there's no third column.
SQL Profiler - I see this:
exec sp_prepare #p1 output,NULL,N'EXECUTE dbo.DimensionLookup WITH RESULT SETS ((
DimensionID int, DimensionField nvarchar(700)))',1
SET FMTONLY ON exec sp_execute 1 SET FMTONLY OFF
So it's trying to use FMTONLY to get the result set data ... needless to say, running SET FMTONLY ON and then running the command in SSMS myself yields .. just the two columns.
SET NOTCOUNT ON - Nothing changed.
So, two other interesting things:
I deployed it out to my local SQL 2012 install and it worked fine, same connections, etc. So it may be a server / database configuration. Not sure what if anything it is, I didn't install the dev server and my own install was pretty much click through vanilla.
Perhaps the most interesting thing. If I remove the join from the procedure's statement so it just becomes
select DimensionID, DimensionField from DimensionTable
It goes back to just sending 2 columns in the result set! So adding a join, without adding any additional output columns, ups the result set to 3 columns. Even if I add 6 more joins, just 3 columns. So one guess is its some sort of metadata column that only gets activated when there's a join.
Anyway, as you can imagine, it's driving me kind of mad. I have a workaround to load the data into a temp table and just return that, but why won't this work? What extra column is being sent back? Why only when I add a join?
Gah!
So all credit to billinkc: The reason is because of a patch.
In Version 11.0.2100.60, SSIS Lookup SQL command metadata is gathered using the old SET FMTONLY method. Unfortunately, this doesn't work in 2012, as the Books Online entry on SET FMTONLY helpfully notes:
Do not use this feature. This feature has been replaced by sp_describe_first_result_set.
Too bad they didn't follow their own advice!
This has been patched as of version 11.0.2218.0. Metadata is correctly gathered using the sp_describe_first_result_set system stored procedure.
This can happen if the specified WITH results set in SSIS identifies that there are more columns than being returned by the stored proc being called. Check your stored proc and ensure that you have the correct number of output columns as the WITH results set.
I have a SQL Server and Cache server and need to combine some data. Most all functions are working, except when I attempt to pass a date with a variable or a parameter.
Below is a test I ran (one of many).
declare #myDate datetime
set #myDate = convert(datetime,'2012-02-01',120)
select * from ccms..dbo.dcdnstat where timestamp > '2012-02-01' -- WORKS
exec( 'select * from dbo.dcdnstat where cdn = ?', 21004) at ccms -- WORKS
exec( 'select * from dbo.dcdnstat where timestamp > ?',#myDate) at ccms -- ERROR 7213
select * from ccms..dbo.dcdnstat where timestamp > #myDate -- ERROR 7322
Msg 7213, Level 16, State 1, Line 9 The attempt by the provider to
pass remote stored procedure parameters to remote server 'ccms'
failed. Verify that the number of parameters, the order, and the
values passed are correct. Msg 7322, Level 16, State 2, Line 11 A
failure occurred while giving parameter information to OLE DB provider
"MSDASQL" for linked server "ccms".
I have tried different date formats, and as shown above I can query on other fields with variables and I can query on date if I use a specific value.
Instead of a "DATETIME" type for your stored procedure parameter, just use "DATE"
(as long as you don't need the time requirements)
I had a problem similar to this today. It had to do with the fact that the calling server and the linked server were not the same version. One was SQL Server 2005 and the other was SQL Server 2008. The problem was due to the fact that the column being queried against at the remote end (2008) was a datetime2 and the calling server (2005) does not support datetime2.
I know this is a little late but I stumbled upon it looking for something similar with the Cache system. Looks like we are working on the same backend system. Mine is the Avaya CCMS system. Here is what I do to pass dates as variables:
DECLARE #myDate DATETIME
SET #myDate = CAST('2012-07-01' AS DATETIME)
SELECT SUM(CallsOffered), SUM(CallsAnswered), SUM(SkillsetAbandonedAftThreshold)
FROM AvayaCCMS..dbo.mSkillsetStat
WHERE Timestamp = #myDate
I was doing something very similar using a Sybase database as the linked server. Just as MobileMon said, I was able to change the datetime to date and it works fine now.
declare #myDate date
set #myDate = convert(datetime,'2012-02-01',120)
Is it possible to change the datetime for a particular database on SQL Server?
Is it tied to the operating system's date/time?
We wish to simulate a future datetime for testing purposes i.e. so the GETDATE() returns a date in the future.
It's got to be in a semi-production (staging) environment so unfortunately changing the OS date / time isn't an option for us.
In an ideal world we'd spin up a virtual server, but also not really an option at the moment.
As stated, by others, No.
A really hacky workaround, would be be to write your own function to return the date you want and have it return GETDATE() when you're done testing, and call that function instead. There's probably some slight overhead in doing this, but it'll do what you need.
Unfortunately it is tied to the OS date and time. See here: http://msdn.microsoft.com/en-us/library/ms188383.aspx
This value is derived from the operating system of the computer on
which the instance of SQL Server is running.
You can always use this and adjust accordingly:
SELECT getutcdate()
Please see below for more information
StackOverflow Question
But there is no way to change the results from a GETDATE() without changing the server's date.
Added:
You could do a EXEC xp_cmdshell 'DATE 10/10/2011' if you wish... but it's not advised.
Another workaround I've had some success with is to add an INSTEAD OF trigger to any table where a GETDATE() value is being inserted and modify it there e.g.:
ALTER TRIGGER [dbo].[AccountsPayableReceivable_trg_i] ON [dbo].[AccountsPayableReceivable]
INSTEAD OF INSERT
AS
SET NOCOUNT ON
SELECT *
INTO #tmp_ins_AccountsPayableReceivable
FROM INSERTED
UPDATE #tmp_ins_AccountsPayableReceivable
SET dtPaymentMade = '01-Jan-1900'
WHERE dtPaymentMade between dateadd(ss, -5, getdate()) and dateadd(ss, +5, getdate())
INSERT INTO AccountsPayableReceivable
SELECT *
from #tmp_ins_AccountsPayableReceivable
(Incidentally, the where clause is there because my test script autogenerates these triggers, adding an update for every datetime column, so I only want to update those that look like they are being inserted with a GETDATE() value.)
I believe you can create a user function that would do the calculation for you and apply that.
http://msdn.microsoft.com/en-us/library/ms186755.aspx
Also, it can be used as the default value for a column.
Bind a column default value to a function in SQL 2005
I'm changing some bad design on a table. The field I'm trying to change holds IIS7 session id's which are long numbers. I'm trying to change the field from nvarchar(20) to int. There are 349,000 records in the table.
SQL Server Management Studio times out after 35 seconds. However, if I check the query timeout setting for the connection it is set at 600 seconds (and I can't change it either).
Is there another timeout setting that could be causing this problem?
Here's the error message I'm getting:
- Unable to modify table.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
I've been able to change several other tables with no problem. Of course, they had fewer rows.
This database is on a shared hosting package at Arvixe.com. Do you think this could be part of the problem?
Can you try to run a T-SQL script instead of doing this using the visual designer?
ALTER TABLE dbo.YourTable
ALTER COLUMN YourColumn INT
Now, this will only work if all rows are truly valid INT values! Otherwise, it'll bomb out at some point....
To check if all your rows are truly valid INT, you could run this query:
SELECT * FROM dbo.YourTable
WHERE ISNUMERIC(YourColumn) = 0
This will select all rows that are not valid numerics ... if you get rows here, you have a problem...
So here is a bit of a strange one...
I have a stored proc that takes 40 seconds to run.
I copy the contents of the stored proc to a new query window, change the 2 input parameters (which are both dates) so they are declared and set, and run the query. It is basically instant, sub 1 second execution.
The only difference is the stored proc takes the 2 dates as parameters.
Anyone got any idea what can make that happen?
(I am running SQL Server 2005)
Recompilation sniffs the parameters, so it can make no difference.
This article explains my statement...
...parameter values are sniffed during
compilation or recompilation...
You need to mask the parameters:
ALTER PROCEDURE [uspFoo]
#Date1 datetime,
#Date2 datetime
AS
BEGIN
DECLARE #IDate1 datetime, #IDate2 datetime;
SELECT #IDate1 = #Date1, #IDate2 = #Date2;
-- Stuff here that depends on #IDate1 and #IDate2
END
As gbn says, this is a parameter sniffing issue. An alternative way to his suggestion is to include the following line at the end of your query:
OPTION (RECOMPILE)
Run the profiler and capture the query plans for the execution. Check to see what the differences are - you may be able to tune the query or force a particular plan.
I had a similar issue and found it was caused because I was setting up the parameter as a DATE but the column it was being compared against in the WHERE clause was in DATETIME so it was like SSMS was converting the data type for every row it was comparing. Changing the parameter data type to DATETIME or masking the parameter as mentioned above resolves the issue.
had a same issue, I tried to resolve Parameter sniffing and also used recompile options but didn't work for me.. then came to know that adding ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES in the update query can resolve my problem..