i have the ff stored procedure
create procedure InsertDetails(
#name varchar(50),
#lastname varchar(50),
#starttime time(7),
#endtime time(7)
)
AS
BEGIN
insert into table (
name,
lastname,
starttime,
endtime
)
values(
#name,
#lastname ,
#starttime,
#endtime
)END
when the stored procedure is executed i enter the following parameters, however i am not sure for the starttime and end time as to what is the format to enter the time in. i tried
08:00:00 and 08-00-00
but i get an error for both Incorrect syntax near ':'.
can you tell me the format its expecting
There's no syntax for specifying time literals1 - you'll need to give a character literal and have the system convert them to time for you.2
So, it would be '08:00:00', for example.
Of course, if you're executing this stored procedure from some other language, then you should see if there are appropriate bindings to allow you to pass the data across as a time parameter (or local language equivalent) rather than passing it as a string at all.
1Bizarrely, T-SQL calls these Constants, but since just about every other language uses the term literals, I choose to use that term instead.
2You don't have to have the system perform the conversion. You may perform an explicit conversion if you want to, but I usually find that this doesn't add anything to the query, except noise.
I got Why you get this error because you did;t mention it into single quote ' '
you are Doing this exec Like exec InsertDetails 's','s',08:00:00,08:00:00
Try to exec Like exec InsertDetails 's','s','08:00:00','08:00:00'
Error Demo
Working Demo
Related
I am trying to get System Datetime for a column when a new row is inserted or updated into a table using stored Proc in MS SQL. How can I achieve it?
I have tried below code
CREATE PROCEDUCE test_Cl_INSERT
#SRC_ID int,
#CREATED_BY datatime
AS
BEGIN
INSERT into dbo.CL_Batch(SRC_ID, Created_BY)
VALUES(#SRC_ID, CURRENT_TIMESTAMP)
END
EXEC dbo.test_Cl_INSERT
#SRC_ID=44
ERROR : #CREATED_BY parameter missing
This will work:
CREATE PROCEDURE test_Cl_INSERT
#SRC_ID int
AS
BEGIN
INSERT into dbo.CL_Batch(SRC_ID, Created_BY)
VALUES(#SRC_ID, CURRENT_TIMESTAMP)
END
EXEC dbo.test_Cl_INSERT
#SRC_ID=44
Your procedure signature is:
CREATE PROCEDUCE test_Cl_INSERT
#SRC_ID int,
#CREATED_BY datatime
You attempt to execute as:
EXEC dbo.test_Cl_INSERT #SRC_ID=44
Do you see something missing? You should. Your procedure has 2 parameters but you provide only 1 when you attempt to execute it. That is your problem. As already noted, you don't use that paramter within the logic of the procedure so why does it exist at all?
You must execute your procedure like this:
EXEC dbo.test_Cl_INSERT #SRC_ID=44, #CREATED_BY = '20201124 12:49';
Notice I just assigned a random value to the parameter since it (the parameter) is not used within your procedure code. That solves the question you ask. However, you have more important issues to consider.
I have created two functions to work with ISO 8601 dates:
CREATE FUNCTION IPUTILS_STR_TO_ISODATE (
#isostr VARCHAR(30))
RETURNS DATETIME
AS
BEGIN
RETURN CONVERT(DATETIME, #isostr, 126);
END;
GO
CREATE FUNCTION IPUTILS_ISODATE_TO_STR (
#date VARCHAR(30))
RETURNS VARCHAR(30)
AS
BEGIN
DECLARE #result VARCHAR(30);
SET #result = CONVERT(VARCHAR(30), #date, 126);
RETURN #result;
END;
GO
I don't get them working correct for some reason. If I do:
select dbo.IPUTILS_ISODATE_TO_STR(dbo.IPUTILS_STR_TO_ISODATE('1965-04-28T12:47:43'));
I get:
apr 28 1965 12:47PM
instead of:
1965-04-28T12:47:43
if I do:
select convert(VARCHAR(30), dbo.IPUTILS_STR_TO_ISODATE('1965-04-28T12:47:43'), 126);
I get:
1965-04-28T12:47:43
Is this a bug or am I doing something wrong?
Why are you not testing these functions individually first and then in combination? If you do test them individually you will likely see the problem ;-). Check the datatype of the #date input parameter on the IPUTILS_ISODATE_TO_STR function: it is VARCHAR(30) instead of DATETIME.
Having the incorrect datatype for the input parameter means that an implicit conversion from a real DATETIME into VARCHAR, but without a specified "style", is happening as the value comes into the function. This is the same as doing CONVERT(VARCHAR(30), #date). And the result of this implicit conversion (i.e. the value stored in #date) is being sent to the SET #result = CONVERT(VARCHAR(30), #date, 126); line.
Also, I would suggest not doing this in the first place (i.e. creating either of these functions) if they are going to be used in SELECT statements or WHERE clauses. Using the CONVERT() function in those places is repetitive, but also much faster. T-SQL scalar UDFs and Multiline TVFs do not perform well and you can slow down your queries by using them. In this particular case there is no real computation / formula being done so you aren't really gaining much outside of not needing to remember the "style" number. Also, T-SQL functions invalidate the query from getting a parallel execution plan. But if these are just being used in simple SET statements to manipulate a variable that is being used in a query, then that should be fine.
I always prefer to use stored procedures for most SQL commands during development.
One example for select statement.I use this Store porcedure
ALTER proc [dbo].[sp_select] (#tbl varchar(200),#col varchar(max),#cond varchar(max))
as
declare #query varchar(max)
if(#cond!=NULL)
begin
set #query='select '+#col+' from '+#tbl+' where '+#cond
end
else
begin
set #query='select '+#col+' from '+#tbl
end
exec(#query)
GO
I am little conscious SQL Injection atacks. This way is safe from such attack or not??
Any suggestion would be appreciated...
Your stored procedure is completely pointless and only makes it harder to write safe code.
SQL injection is not magic; it's simply input strings with quotes.
Stored procedures do not magically defend against it; they simply encourage you to pass user input as parameters (which you aren't doing).
The correct way to protect against SQL (and other forms of) injection is to change your application code to never concatenate arbitrary text (especially user input) into a structured langauge (such as SQL, HTML, or JSON).
Instead, use parameters, a JSON serializer, or a proper HTML escaper, as appropriate.
No. It very vulnerable to SQL Injection. For example, suppose someone does
exec dbo.sp_select '#Dummy', '(Select Null) As x; Update Employee Set Salary = 1000000 Where EmployeeName = ''me''; Declare #Dummy Table (i int); Select Null ', null
then the query that you build and execute is
select (Select Null) As x; Update Employee Set Salary = 1000000 Where EmployeeName = 'me'; Declare #Dummy Table (i int); Select Null from #Dummy
and your stored procedure which is supposed to only do selects has just updated my salary to 1,000,000.
I’ve got a script that I’ve created for our production line where the user enters some variables into the script before executing. The Problem is that the variables are NVARCHAR(9) and if the user inputs a 10 character sting the last character is cut off (as expected) what I want to know is how can I have SQL throw an error if they enter a value that is too long? This issue stems from users fat fingering their inputs.
Example:
Valid input -
DECLARE #ClientCode NVARCHAR(9)
SET #ClientCode = N'ABCDEFGHI'
SELECT #ClientCode
Results
ABCDEFGHI
Invalid input –
DECLARE #ClientCode NVARCHAR(9)
SET #ClientCode = 'ABCDDEFGHI'
SELECT #ClientCode
Results
ABCDDEFGH
What I’m hoping for is a setting that will have SSMS raise an error. What I’m hoping to avoid is something like -
DECLARE #ClientCode NVARCHAR(50)
...
IF LEN(#ClientCode) > 9
RAISERROR('Too long dummy.',16,1)
Thanks for you help
Please see SQL Server silently truncates varchar's in stored procedures - SQL Server cannot be set to automatically raise truncation errors for inserts inside of a stored procedure, so you have to perform the check yourself. You can do this in the stored procedure (the code you listed as "hoping to avoid") or you can validate beforehand in the client application.
I've also been looking at the question Scott Chapman references in his answer, however, I found igorp's answer midway down interesting, I had to hack it a bit to fix the SQL but it can work:
declare #p1 varchar(max), #p2 varchar(max)
select #p1 = 'abcd'
declare #p1Int varchar(2), #p2Int varchar(3)
declare #test table (p1 varchar(2), p2 varchar(3))
insert into #test (p1,p2) values (#p1, #p2)
select #p1Int=p1, #p2Int=p2 from #test
I cannot store the date data type variables using stored procedure. My code is:
ALTER PROCEDURE [dbo].[Access1Register]
-- Add the parameters for the stored procedure here
#MobileNumber int,
#CitizenName varchar(50),
#Dob char(8),
#VerificationCode int
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
select CAST(#dob As DATE)
Insert Into Access1 (MobileNo,CitizenName,Dob,VerificationCode)
values(#MobileNumber,#CitizenName,#Dob,#VerificationCode)
go
If I exec this procedure it is executing, but there is an error occured in the date type variable. It's raising the error as invalid item '-'.
It depends on how you pass in the #Dob values.
Your best bet is to use the ISO8601 format - 'YYYYMMDD' - since that will always convert to DATE properly - regardless of your language and regional settings on your SQL Server machine.
It depends on the date format that you pass.
If it is 'mm-dd-yy' you can use CONVERT(DATE, #Dob, 110), if it is 'dd-mm-yy' then CONVERT(DATE, #Dob, 105).
In which format you are passing the #Dob values? And what error you are getting exactly?
If you will pass the #Dob values in the format of mm-dd-yy, it should work correctly and no errors will be there.