Error catching a function error in TSQL - tsql

I am working with a SQL Server 2005 database table that is currently storing dates as varchars. This is outside of my control. For ease of reporting, I would like to create a view that converts these varchar dates to datetime fields.
The varchar dates are formatted for the most part, except for the occasional typing error.
DateString
----------
2001/01/02 -- most of the fields
2002/0601 -- typo, missing slash between month and day
2004/02/30 -- typo, no 30th of February
Because the dates are already formatted, I'm using the cast function to convert them to datetime.
cast(DateString as datetime)
The problem is when the cast function comes across an incorrect date, the query ends in error.
Is there are way to wrap just the function in a try...catch block? I see it is possible to wrap an entire query in a try...catch block, but the full query has multiple casts that must be done, and any combination could have typing errors.

I would use the built-in ISDATE() function. You can then write a CASE statement within your SELECT statement to either return the parsed date or either a null or some other result. Or, you can place it directly in the WHERE clause to only return those rows where there is a valid date.
A possible solution with the ISDATE() function in the SELECT list may look like:
select case
when ISDATE(DateString) = 1 then cast(DateString as datetime)
else null --or other error result
end as CastedDate
from TableName

If the logic is complicated (e.g. you want to try to correct the errors, such as missing slash, or nearest day in the case of 30th FEB), then one option is to create a user-defined function that contains the date parsing logic (string to date) logic in it, complete with error handling (e.g. scenario checking before casting). Then in the query, call the user defined function.
An outline:
CREATE FUNCTION udf_ParseDateString
(
#DateString nvarchar(20)
)
RETURNS DateTime
AS
BEGIN
DECLARE #returnDateTime datetime
-- Do any string checking, and date casting here
-- #DateString -> #returnDateTime
return #returnDateTime
END
Note that you won't be able to use TRY-CATCH in a UDF.
Alternatively, if your logic is simple, you could just use a cast inline, as suggested here.
SET DATEFORMAT ymd;
-- Incorporate this into query.
SELECT CASE WHEN ISDATE(#yourParameter) = 1
THEN CAST(#yourParameter AS DATETIME)
ELSE YourDefaultValue
END
If you were using SQL Server 2012, you could use the TRY_CAST function.

Related

How to properly insert Timestamp using plpgsql and EXECUTE format...USING dynamic SQL

I have a dynamic SQL statement I'm building up that is something like
my_interval_var := interval - '60 days';
sql_query := format($f$ AND NOT EXISTS (SELECT 1 FROM some_table st WHERE st.%s = %s.id AND st.expired_date >= %L )$f$, var1, var2, now() - my_interval_var)
Regarding my first question, it seemed to insert the Timestamp correctly (it seems) after the now() - my_interval_var computation. However, I just want to make sure I don't need to cast anything or something, because the only way I could get it work was if I used %L, which is the string literal Identifer. Or does postgres allow direct comparisons with Strings that represent Time without a cast?, like
some_column <= '2021-12-31 00:00:00'; // is ::timestamp cast needed?
Second of all, regarding the sql_query variable that I concatenated an SQL String into above, I actually wanted to skip the Format I did, and directly inject this sql_query variable into an EXECUTE...FORMAT...USING statement.
I couldn't get it to work, but something like this:
EXECUTE format($f$ SELECT *
FROM %I tbl_alias
WHERE tbl_alias.%s = %L
%s ) USING var1, var2, var3, sql_query;
Is it possible to leave the Dynamic SQL Identifiers %I %L and %s inside the variable and FORMAT it at the EXECUTE... level? Something tells me this isn't possible, but it would be really cool.
Also last question I didn't want to add, but I feel someone might have a quick answer.
I was using the ]
FOR temprecord IN
SELECT myCol1, myCol2, myCol3
FROM %I tbl',var1)
LOOP
EXECUTE temprecord.someColumnOnMyTbl;
END LOOP;
...but I could not for the life of get the EXECUTE temprecord.someColumnOnMyTbl statement to work when I made the query dynamic. I tried everything identifier, using FORMAT, USING...
I thought columns were strings like %s because I do that for columns all the time when they are aliased like alias.%s = 'some string literal'
ANyway, I couldn't get it to work, I wanted to make the column name dynamic but tried all these things
EXECUTE format($f$ %I.%s $f$, var1, var2);
EXECUTE format($f$ %$1.%$2 $f$) USING var1, var2;
EXECUTE format($f$ %I.someColumnOn%s $f$, var1, var2);
EXECUTE format($f$ $1.someColumnOn$2 $f$) USING var1, var2;
Anyway, I tried more stuff than that, but I actually got some data from the DB when I made the temprecord variable an %I but I am Selecting 3 columns and it looked like sommething got jacked up with the second identifier because I got a syntax error and it looked like it was trying to concatenate all 3 columns of the query results...
I did try hardcoding it and that worked fine... any help appreciated!
String literal is unknown type value. Postgres always does cast to some target binary format. The type is deduced from context. When you use function format, and %L placeholder, then any binary value is converted to string, and escaped to Postgres's string literal (protection against syntax errors, and SQL injection). When you use USING clause, then the binary value is passed directly to executor. It is little bit faster, and there is not possibility to lost some information under cast to string. Without these points, the real effect of %L and USING clause is almost same.
Your type of variable is timestamp. Probably type of expired_date column is date type. So some conversion timestamp->date is necessary.
Function format is just string function. It just make string. For better readability it supports placeholders, that ensure correct escaping and correct result SQL string. %L is same like calling function quote_literal and %I is same like quote_ident (for column, table names). %s inserts string without escaping and quoting. The result of format function (when you use it in EXECUTE command) should be valid SQL statement. You can use it in RAISE NOTICE command, and you can print result to debug output. Usually it is good idea
DECLARE
query text;
x date DEFAULT current_date
y int;
BEGIN
query := format('.... WHERE inserted = $1', ...);
RAISE NOTICE 'dynamic query will be: %', query);
EXECUTE query USING x INTO y;
...
Clause USING allows using parameters in dynamic SQL (EXECUTE clause). Usually, the format's placeholdres should be used for table or column names, and USING for any other.
For types date and timestamp (scalars basic types) the following execution will be on 99.99% same:
EXECUTE format('select count(*) from foo where inserted = %L', current_date) INTO ..
EXECUTE 'select count(*) from foo where inserted = $1' USING current_date INTO ..
You cannot to use query parameters on column name or table name positions. This is limit of USING clause. But for any other cases, this clause should be used primary.

Oracle stored procedure an INTO clause is expected in this SELECT statement

I am having a stored procedure mentioned below.
create or replace
PROCEDURE example(
in_start_date IN VARCHAR2,
in_svc_provider IN a_message.msg_service_provider%type,sell OUT number)
IS
BEGIN SELECT COUNT(*) as sell
FROM a_message b1 WHERE TO_CHAR(b1.msg_when_created,'YYYY-MM-DD') = in_start_date
AND b1.msg_trans_type = 'SELL'
AND b1.msg_service_provider = in_svc_provider;
end;
While executing the stored procedure I am getting following error.
Error(11,1): PLS-00428: an INTO clause is expected in this SELECT statement
Can you please provide me the resolution for this issue.while executing the same command in sql it is working fine but in stored procedure compilation error is occurring it means in stored procedure INTO replacing AS will give the same output please clarify.
The error message is fairly self-explanatory; the PL/SQL version of a SELECT requires an INTO clause so the result of your query has somewhere to go. You already have an OUT parameter to put the value into:
create or replace
PROCEDURE example(
in_start_date IN VARCHAR2,
in_svc_provider IN a_message.msg_service_provider%type,
sell OUT number)
IS
BEGIN
SELECT COUNT(*) INTO sell
FROM a_message b1
WHERE TO_CHAR(b1.msg_when_created,'YYYY-MM-DD') = in_start_date
AND b1.msg_trans_type = 'SELL'
AND b1.msg_service_provider = in_svc_provider;
end;
The SELECT is now INTO your OUT parameter, and its value will be available to whoever calls your procedure.
This only works if your query will always return exactly one row. If it doesn't return anything then you'll get a no-data-found exception; if it returns more than one row you'll get a too-many-rows exception. And you need to have a variable for each column your query returns - only one in this case. You can also declare a local variable (between IS and BEGIN) to hold temporary values that you will manipulate within the procedure, but you don't need that here either.
When you compiled your procedure it would have said it compiled with warnings, because of that syntax error. If you created it in SQL*Plus or SQL Developer, and maybe some other tools, you could have seen the error straight away by issuing the command show errors, or at any time by querying the user_errors view. When you called the procedure it was invalid and was automatically recompiled, which just regenerated the same error as nothing had changed; that's when you saw the PLS-00428 message. It's better to look for errors at compile time than wait for recompilation at execution time.
Incidentally, it's generally better to convert a fixed value into the data type used by your table, rather than the other way round. When you do this:
WHERE TO_CHAR(b1.msg_when_created,'YYYY-MM-DD') = in_start_date
... every column in your table has to have its msg_when_created DATE value converted to a string to be compared to the in_start_date string, which would prevent an index on that column being used. It's preferable to do:
WHERE b1.msg_when_created = TO_DATE(in_start_date, 'YYYY-MM-DD')
or if your column has a time component:
WHERE b1.msg_when_created >= TO_DATE(in_start_date, 'YYYY-MM-DD')
AND b1.msg_when_created < TO_DATE(in_start_date, 'YYYY-MM-DD') + INTERVAL '1' DAY
It would be even better to make your caller convert the value to a DATE so you don't have to worry about matching a passed format:
...
in_start_date IN a_message.msg_when_created%TYPE,
...
WHERE b1.msg_when_created >= TRUNC(in_start_date)
AND b1.msg_when_created < TRUNC(in_start_date) + INTERVAL '1' DAY
use into function
example: select count(*) into cnt_length from Table

Use Expression Result (e.g. Month) as Column Name in SQL Express

I'm writing an SQL expression and I'd like to use the current month as the column name/header.
Code:
Select MONTH(GETDATE()) AS MONTH(GETDATE())
FROM SomeTable;
Error:
Error 102: Incorrect syntax near 'GETDATE'.
This is for a school project and I'm not sure if it's possible. If it is, I'd like to possibly convert that Month number to the actual month name. Thanks in advance.
Oh, and I'm using LinqPad to test the queries on a remote DB and SQL Express Server (Transact-SQL).
Cheers,
Lindsay
I think, You can not use function in column alias, if you try to then you get this error incorrect syntex "Expecting ID, QUOTED_ID, STRING, or TEXT_LEX" which means the alias text has to be hard coded.
I would suggest, you use your front end application to set current month as header, instead of relying on back end sql query.
The alias for your computed columns shouldn't contain any function - just text:
SELECT
MONTH(GETDATE()) AS 'Month'
FROM
dbo.SomeTable

make a column in sybase default to the current date/time of row insertion

I have a sybase 15 DB and for one of my tables, I want to make a column default to the current date/time of the row insert. Is this possible?
In a sybase text, the following is said:
ALTER TABLE sales_order
MODIFY order_date DEFAULT CURRENT DATE
On my DB this doesn't do anything, as CURRENT DATE is not recognized.
using getDate() is a valid solution, you must have had a syntax error. Try it like this:
create table test_tbl (
date_data DATETIME default getDate() NOT NULL
)
Try using getDate() instead
... DEFAULT GETDATE() is correct. the case is irrelevant; mixed case may indicate a Java method, but it is a straight TSQL Function. Please post the exact error msg if you want further assistance.
Also, the ALTER TABLE method sets the Default for future INSERTS; if you want the existing data changed, you need to UPDATE (good for small tables) or unload/reload the table (demanded for the large).
Watch the NULL/NOT NULL: you do not want to change that without understanding. Again, the existing/future issue needs address. NOT NULL prevents NULL being explicitly passed as an INSERT VALUE.
CURRENT_DATE is a SQL standard that isn't universally adopted.
As noted elsewhere the getdate() T-SQL function should be used instead.

Stored Procedure vs User Defined Function for Error Handling

My ERP database uses non-nullable datetime fields. However, it enters '' for the datetime when one isn't available and returns ‘1900-01-01 00: 00: 00.000’ as the value.
I want to suppress the 1900 dates while stripping the Date only from the Datetime field. I created the following UDF to do that:
CREATE FUNCTION ExtractDate(#DirtyDate DATETIME)
RETURNS VARCHAR(10) AS
BEGIN
DECLARE #CleanDate VARCHAR(10)
SELECT #CleanDate =
CASE
WHEN #DirtyDate = '' THEN ''
ELSE CONVERT(VARCHAR(10), #DirtyDate, 101)
END
RETURN #CleanDate
END
This works, but I wanted to add error handling in case a user used it on something other than a datetime field. After some Googling, I found out that this isn't possible with UDF.
However, if I write this as a stored procedure, would I still be able to call it in a select statement? Can someone point me in the right direction?
No, you can't call a stored proc in a select statement.
I applaud your ambition in wanting to include error handling, but your best bet is to check for that on the app side - don't allow people to use the function on non-date fields.