I've encountered a quite strange behavior of a procedure called from various environments. The procedure is implemented in Oracle environment.
function licence_update(p_licence ax_import_licence_vw%rowtype) return number;
When I run the statement from Oracle everything is allright:
declare l_res number := null; begin l_res := licence_update(p_licence); end;
But when the same procedure is called from MS SQL using OPENROWSET I get an error
ORA-1861: literal does not match format string.
EXECUTE ('BEGIN licence_update(p_licence); END;') AT LinkedServer;
There is a date attribute in the view ax_import_licence_vw, that certainly cause the error. If I take out this attribute the procedure always finished successfully.
So, I guess it happens because of NLS_DATE_FORMAT that is set up differently when the procedure is called. I took a look at the log table and found out the following information about nls_date_formats:
from Oralce: DD.MM.RR
from MS SQL: YYYY-MM-DD HH24:MI:SS
What kind of converting operation should be done to that date attribute to get rid of this error?
Related
The "Incorrect syntax near '#P1" from a TSQL stored procedure seems to be a common issue but none of the advice that I have seen has solved my problem. My query works in SQL Management Server Studio is not working from my JDBC code.
ALTER PROCEDURE [dbo].[Get-ErrorLogByWorkflowId] (
#workflowId AS NVARCHAR(255) -- removed second parameter to simplify: , BIGINT #numSecondsOfErrors=300
)
AS
BEGIN
...
This is the Java code using JDBC that I use to call the stored procedure:
CallableStatement stmt = conn.prepareCall("{ call dbo.Get-ErrorLogByWorkflowId(?) }");
stmt.setString(1, workflowId);
//second parameter removed to simplify call: stmt.setLong(2, seconds);
ResultSet rs = stmt.executeQuery();
I have tried calling the stored procedure both with and without brackets, e.g., [dbo][Get-...]. I have also tried declaring the parameter both as a VARCHAR and NVARCHAR. What should I do to correct this?
Note: I had previously observed some odd problems handling names beginning with "Get-", but the prefix is part of my company's standards and I eventually got such queries to work.
#AlwayLearning was correct. Uniformly using brackets around the portions of the names of the stored procedure worked - so I now use [dbo].[Get-ErrorLogByWorkflowId] to be on the safe side
I am new to M.
When trying to call a SQL Server Store Procedure in M, I want to pass parameters to the exec command where SQL is looking for smalldatetime types. I have defined my parameters in PowerQuery as Date/Time, however, when they are added to the exec command I get various errors depending on how I include them.
PowerQuery Parameters
PowerQuery Code
Error Returned
If I change my query to convert the parameters from datetime to text using DateTime.ToText(startDate) I then get the error noting that my stored procedure needs a smalldatetime parameter type as follows, which is of course obvious:
DataSource.Error: Microsoft SQL: Error converting data type varchar to smalldatetime.
I also want to be able to submit the parameter in 'yyyy/mm/dd hh:mm' format, although if SQL will understand the month and day properly as my users will be in different regions of the world, then I will be happy. If I need to modify my stored procedure to work better with this, I can do that also.
Any help appreciated with thanks.
I am trying to run the below procedure from SSIS using SQL Task.
ALTER PROCEDURE [dbo].[sp_Previous_Load_Dt_Tm]
AS
BEGIN
SELECT Extract_Dt_Tm = ISNULL(CONVERT(VARCHAR(20), MAX([Previous_Load_Date_Time]),120),'')
FROM [Test_table] WITH (NOLOCK)
END
I am returning as below
When I use the variable type as String in SSIS :
If I update the variable type to date it gives me the value:
Question ) I am not sure why its returning a date when I am converting the date to varchar in the procedure.
Is this happening at run time?
If you change the variable type to datetime at design time, and the string returned from the stored procedure is written to it during execution, this would most likely be due to SSIS performing an implicit conversion, i.e. successfully parsing a datetime value from the string.
I imagine the images you posted are at design time, with the string not having been written yet, and the datetime having defaulted to the current date and time?
I just removed and re added the variable. And it worked!!!! Not sure what the issue was.
I have a stored procedure that takes a datetime parameter which is passed in as a string. Such as this:
Procedure:
CREATE PROCEDURE [dbo].[MyFancySP]
#MyStartDate datetime = NULL,
#MyEndDate datetime = NULL
AS
....
Call:
EXEC [dbo].[MyFancySP]
#MyStartDate = N'01/01/2012',
#MyEndDate = N'03/01/2012'
The stored procedure has been working like this forever. Now, here's the interesting part. As soon as I change the date to 03/27/2012 or past it, I get the following error: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
The only place in the stored procedure where the dates are used is in the where clause. In case it has to do with it, I'll copy it in here as well:
WHERE
((#MyStartDate IS NOT NULL AND #MyEndDate IS NOT NULL
AND d.SomeDate >= #MyStartDate AND d.SomeDate <= #MyEndDate)
OR #MyStartDate IS NULL AND #MyEndDate IS NULL)
Any ideas why I'm getting the out of range exception on March 27th or beyond? This is running on SQL Server 2008 R2 by the way.
Thanks!
Execute the following on each new database connection.
SET DATEFORMAT DMY
After you do this, your problem should disappear. I suspect that your issue is conditioned by a combination of server locale, and whether the day-of-month is 13th to 31st or not.
Not only that you see the error, you may also be fetching data for incorrect periods without noticing; other layers of your software may be correcting for that, but maybe only in some cases.
What type is d.SomeDate? Is it a NVARCHAR by any chance? That would explain it, as the WHERE clause would contain in such case an implicit conversion that the rules of Data Type Precedence state that should occur as a DATETIME. The apparent randomness of the error occurs due to the simple fact that the query scans rows that have invalid dates in the d.SomeDate field. In such a case you're dealing with data purity issues and you should fix your tables, preferably by making the column a DATETIME.
In addition:
always use the canonical date format YYYYMMMDD (no delimiters) in string representation: EXEC [dbo].[MyFancySP]
N'20120101', N'20120301';. This format is independent of the host locale, DATEFORMAT and LANGUAGE settings, .
Read Dynamic Search Conditions in T-SQL. WHERE column=#value or #value is null stops query performance optimizations dead on its track. Read the article.
I have some Java code that accesses SQL Server 2005 which looks something like this:
CallableStatement cstmt = ...;
... // Set input parameters
cstmt.registerOutParameter(11, Types.INTEGER);
cstmt.execute();
int out = cstmt.getInt(11);
And the following exception is thrown from the last line:
com.microsoft.sqlserver.jdbc.SQLServerException: The value is not set
for the parameter number 0.
at com.microsoft.sqlserver.jdbc.SQLServerException.
makeFromDriverError(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
skipOutParameters(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
getOutParameter(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
getterGetParam(Unknown Source)
at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
getInt(Unknown Source)
at org.jboss.resource.adapter.jdbc.WrappedCallableStatement.
getInt(WrappedCallableStatement.java:192)
The stored procedure being called looks something like this:
CREATE PROCEDURE dbo.stored_proc ( -- 10 input parameters
, #out_param INT OUTPUT) AS
-- Variable declarations
SET #out_param = 0
-- Do processing...
SET #out_param = 1
Since the output parameter is set to zero on entry to the stored procedure, under what circumstances could the value not be set? Or am I misinterpreting the error message?
This error is reproducible with:
SQL Server JDBC Driver 1.2
SQL Server 2005 (64-bit) service pack 2
SQL Server 2005 (64-bit) service pack 3
Update: It seems to be occuring as a result of the -- Do processing... part of the stored procedure. Removing this eliminates the error. There's too much code to reproduce here, what I'd like is some pointers to possible causes to narrow down likely candidates.
Update: Injecting errors (e.g. divide by zero) into the -- Do processing... part of the stored procedure does not cause this exception to be thrown (instead, as expected, the execute() call fails with an appropriate error message).
Update: Decompiling the com.microsoft.sqlserver.jdbc.SQLServerCallableStatement class suggests that 'parameter number 0' is the stored procedure return value.
Update: I have been unable to reproduce this by calling the stored procedure directly through Management Studio.
Update: The ultimate cause of this error seems to be a deadlock in the stored procedure. Usually, however, deadlocks cause the execute() call to fail with a SQLException wrapping SQL Server error code 1205...
on your parameters, are you just declaring them or are you setting them to a default value? try setting them to a default value of null or something and see if you still get the error.
sql server doesn't like it if you have a parameter not set to a default value and you don't pass a value to it when you exec the stored procedure.
Are you registering the output parameters? According the the docs "All OUT parameters must be registered before a stored procedure is executed."
There are a couple things that come to mind:
You haven't got a RETURN x (where x is an INT representing the outcome of processing, 0 = success, anything else represent a warning or an error).
Your client code doesn't assign a parameter for the return value in addition to your output parameter.
Hope this helps,
Bill
Decompiling the
com.microsoft.sqlserver.jdbc.SQLServerCallableStatement class suggests
that 'parameter number 0' is the stored procedure return value.
Thats correct. If your stored procedure definition has 11 input/output parameters, you actually need to define 12 in your calling code. Parameter 0 is the return code.
For example with a SP with one input and one output parameter, in SSMS you run this:
DECLARE #ReturnValue INT
DECLARE #P1 INT, #P2 INT
EXEC #ReturnValue= YourSP(#P1,#P2 OUTPUT)
You actually have three parameters to deal with here, not two.
In case anyone still getting this problem on SQL server 2008.
I had the same problem on an update statement with trying to set a Timestamp for a DateTime field. The offending field was in a where clause at a different index from the reported one.