I'm using Linq-to-SQL query and using stored procedure in that. I'm getting error :
Specified cast is not valid.
How to solve it ?
Check your TDetail.AMOUNT values.
Your error is not when casting to an array, but rather in the Convert.ToDouble(TDetail.AMOUNT).
Run your stored proc with those same arguments (in SSMS or Visual Studio), and try to determine which value in TDetail.AMOUNT is causing this problem.
You're seeing this exception being thrown when you cast to an array, but it would happen whenever you evaluated your LINQ query. It's nothing to do with ToArray(). It could be ToList(), and you'd find the same exception.
Related
UPDATE 11.15.2022
I have conducted extensive testing and found the pattern of problem here. Once again, what's strange is this ONLY happens if you pass a function as a parameter to the originating Stored Procedure; passing a hardcoded value or variable works just fine.
The issue is when the Stored Procedure calls another Stored Procedure that checks ##read_only to see if it can WRITE to the database. I confirmed removing any code that writes data fixes the issue -- so ultimately it appears passing a STATIC value to the SP causes the procedure execution to bypass any writing (as expected) because of the IF ##read_only = FALSE THEN ...write...
It seems passing a function somehow causes MySQL to compile a "tree" of calls and subcalls to see if they CAN write rather than if they DO write.
It appears the only way to work around this is to pass the parameters as variables rather than function calls. We can do this, but it will require substantial refactoring.
I just wonder why MySQL is doing this - why passing a function is causing the system to look ahead and see IF it COULD write rather than if it does.
We have a Read Replica that's up and running just fine. We can execute reads against it without a problem.
We can do this:
CALL get_table_data(1, 1, "SELECT * from PERSON where ID=1;", #out_result, #out_result_value);
And it executes fine. Note it's READS SQL DATA tagged. It does not write anything out.
We can also do this:
SELECT get_value("OBJECT_BASE", "NAME");
Which is SELECT function that is READ ONLY.
However, if we try to execute this:
CALL get_table_data(1, get_value("OBJECT_BASE", "NAME"), "SELECT * from PERSON where ID=1;", #out_result, #out_result_value);
We get the error:
Error: ER_OPTION_PREVENTS_STATEMENT: The MySQL server is running with the --read-only option so it cannot execute this statement
We're baffled at what could cause this. Both the SP and function are read-only and execute individually just fine, but the second we embed the function result in the call of the SP, the system chokes.
Any ideas?
So AWS cannot figure this out. The issue only happens when a function is passed as a parameter to a stored procedure that calls another stored procedure (not even passing the value of the function) that has a ##read_only check before doing an INSERT or UPDATE. So for some reason, the system is doing a pre-scan check when a function is passed vs. a variable or hardcoded value.
The workaround is to pass the function value as a variable.
I'm going to report this issue to Oracle as it might be some sort of bug, especially given the function is DETERMINISTIC.
I'm migrating javascript udf to sql udf in snowflake. In javascript udf there is try catch block to handle exception. How can I implement the same in SQL udf.
Snowflake SQL user defined functions can’t include execution handling. The function definition needs to be a SQL expression, not a Snowflake Scripting block.
The function definition can be a SQL expression that returns either a scalar (i.e. single) value or, if defined as a table function, a set of rows.
Your choices are to code the UDF to avoid triggering any error condition that you wanted to trap (e.g. with a CASE to avoid all “troublesome” input values) or use a JavaScript UDF for any place where exception handling can’t be avoided.
P.S. post a new question with your actual code if you want help on if your use case can be implemented in a SQL UDF
I've declared an handler which will handle SQLEXCEPTION, in the clean up code i had it do SELECT 'My Handle';, i ran a script that fails because of a primary key violation and it worked cause i got my output.
the problem with DECLARE ... HANDLE FOR SQLEXCEPTION is that when there is an error it will run though it's doesn't say what error triggered it, so i want to output the error
How do i output the SQL Error using a MySQL Query, i don't care if i can only output the error code/id i just need something to output giving me an indication on what the error is so i can fix the problem
EDIT: in case if it's not obvious, this code is in an SQL Procedure
There is nothing in the DECLARE HANDLER documentation on this functionality. You could handle the errors MySQL returns to your application and print or log them that way.
I actually haven't used any handles, but i think you can make your code into a stored procedure and then run the stored procedure!! You might find MySQL accepts what you are trying to do then.
I have recently joined a team where they are using JSON serialization to pass parameter arrays to SQL Server stored procedures where they are then deserialized and the required values extracted i.e. Each stored procedure has a '#Parameters' parameter of type VARCHAR(MAX). The framework creating and executing the command is written in C# and uses standard .NET types (SqlCommand, SQlParameter) etc.
It appears that when the serialized content is greater in length than a threshold that the stored procedure is not being properly executed but no exceptions are raised. Nothing appears to happen. Running SQL Profiler I have observed that there is no attempt to execute the stored procedure in SQL Server.
For example:
In one case there are just 30 instances of a type with no more than eight properties being serialized. The serialization succeeds and the value is assigned to the sql parameter in the parameters collection of a SqlCommand (there is only one parameter). The command is executed but nothing happens. If there are fewer occurrences of a type then it succeeds. When it does not succeed an exception is not being raised.
Using:
SQL Server 2008
C# .NET 4.0
JSON Serialization provided by Newtonsoft.
The SqlParameter in code is created as a varchar max.
Client Server architecture - there are no intermediary services.
Does anyone know of a limit for JSON serialized values being passed as a sql parameter with a SqlCommand or have any ideas as to what might be causing this behaviour?
I've figured out what was happening in my case. It had nothing to do with the serialziation of the value in a sql parameter as I found that if I waited long enough (5 -7 minutes in my case) that the procedure eventually executed.
In the stored procedure there is a cursor being used to extract the records of interest (this is a batch update procedure). This cursor was calling the CLR function to deserialize the Json for each value it required. By inserting the desirialized data into a temp table for use in the cursor the 'issue' was resolved.
I'm trying to use an Execute SQL Task in SSIS 2008 to map a store procedure output parameter to a package variable.
The package variable is SSIS type DateTime and the store procedure parameter is SQL type DATETIME.
The SQL Statement is EXEC GetCurrentDate #CurrentDate=? and in the parameter mapping screen, the parameter is mapped to the package variable with direction Output and Data Type DBTIMESTAMP specified.
When I run the package I get the following error:
[Execute SQL Task] Error: Executing
the query "EXEC GetCurrentDate
#CurrentDate=? " failed with the
following error: "The type of the
value being assigned to variable
"User::CurrentDate" differs from the
current variable type. Variables may
not change type during execution.
Variable types are strict, except for
variables of type Object. ". Possible
failure reasons: Problems with the
query, "ResultSet" property not set
correctly, parameters not set
correctly, or connection not
established correctly.
If I run a trace on the query being run I see the type is being assumed as datetime2:
declare #p3 datetime2(7)
set #p3=NULL
exec sp_executesql N'EXEC GetCurrentDate #CurrentDate=#P1 ',N'#P1 datetime2(7) OUTPUT',#p3 output
select #p3
Does anyone know why it is assuming the type is datetime2?
Thanks
Found the answer on a Micorsoft Connect bug report:
We are closing this case as this is expected behaviour and is a result of the new sql datetime type change. You are using a native oledb connection manager for sql task, in the process of COM interop, we use VARIANT to hold the value and the only way to prevent data loss is to store the value as BSTR variant. If you change User::dateParam to String type it will work, or you can switch to use managed connection manager to bypass the COM interop.
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=307835
Try specifying the inout/output parameters as DATE rather than DBTIMESTAMP in the SSIS task.
This certainly works in SSIS 2005 packages I've worked on.
It's also worth taking a look at this link, which covers this as well as a couple of other issues with SSIS and dates.