I've written a stored procedure that takes in a date parameter. My concern is that there will be confusion between American and British date formats. What is the best way to ensure that there is no ambiguity between dates such as 02/12/2008. One possibility would be for users to enter a date in a format such as 20081202 (yyyymmdd). Is there any way to validate that without using sub strings? Alternatively dates could be entered as 02-Dec-2008(dd-mmm-yyyy), but again verification is not trivial and there are potential issues with users who do not use English.
Further to the first three answers . . . One issue is that I'm expecting this stored proc to be called directly without a front end so validation ouside of the proc is not an option. Is it a good idea to take the day, month and year as separate parameters?
You won't have any problems whatsoever if you'd use parameters in your sproc:
create proc dbo.Sproc
#date datetime
as
...
If you declare the parameter as being of type DATETIME or one of the other typed date/time types in SQL Server, which you should, then there is no ambiguity; it represents a particular date and time. The type of validation you're talking about should happen outside the stored procedure, not inside.
OK from your comments and edit, it appears the issue is with the way people call the SP rather than actually within it. To that end, you simply need to train your users to use sortable date format, i.e.
yyyy-MM-dd HH:mm:ss
And then there is no ambiguity. Anybody who is allowed near a database should be aware of localisation issues and should always be using a non-ambiguous format like this one when entering dates.
I've ended up taking a string paramater for the date and require users to enter the month as a word. I check the input is a valid date by converting it to date. To ensure the month is entered as a word, I use the like comparator to compare the input string with "%Jan%" or "%Feb%" or "%Mar%" etc.
If your proc accepts the date as a datetime parameter then there is little you can do to validate that the desired format is ddmmyyyy and not mmddyyyy. It all depends on how the user entered the date and how it was passed to SQL.
For example: On a web page i could add a parameter like this
command.Parameters.AddWithValue("#mydate",mydateVar.ToString("dd/MM/yyyy"));
OR
command.Parameters.AddWithValue("#mydate",mydateVar.ToString("MM/dd/yyyy"));
And SQL will just insert what its given as long as the string can be cast to a date correctly. It wont know the format you want to use so it will try to cast to its system default format.
A solution i use although it may not be applicable in your situation is to have users enter all dates in whatever frontend you have in the dd-MMM-yyyy format. I can then be sure of the format before i insert into the DB. I use that format everywhere to keep it all the same throughout the app.
You said that you are expecting this stored proc to be called directly without a front end and validation ouside of the proc is not an option.
In that case the users will be inserting data directly, I also believe that in this case it is for internal use only (as the stored proc is going to be called directly)
So I think you have 2 options
if you have disciplined users you can agree on one of the safe formats: ISO yyyyddmm, or ISO8601 yyyy-mm-dd Thh:mm:ss:mmm if you need a time part as well
otherwise take 3 parameters: year, month, year and perform some validation inside the stored procedure
I say take a datetime and train them to use the ODBC canonical form of a date as in this example:
EXECUTE uspMyProc {d '2009-02-11'}
If you take a date that you have to parse, whether it be a string or the year, month and day as separate integer arguments, then you have to deal with days out of range for the month and year. Some functions that take those automatically advance or move backwards the day on you. Thus the trick of sending 0 for the day and getting the last day of the previous month. Others return an error. But handling that stuff yourself is probably not worth reinventing the wheel.
If you absolutely have to because novices will be running it directly (why would novices be running stored procedures directly?), I'd take three separate arguments and pass the concatenated date as a string in the format YYYY-MM-DD through ISDATE to verify the parameters and exit if it isn't valid.
Related
I would like to convert dates I receive from timezone 'Europe/Warsaw' to UTC. I have tried to find suitable libraries in C to create a Datastage routine. I did not find anything that would allow to flexibly change the source timezone keeping in mind the change from summer to winter time (daylight). Another way is to use a database function, e.g. in DB2, but currently I am trying to solve the problem without creating stored procedures. Anyone solved a similar problem?
I get the input date in the format 'YYYY-MM-DD HH:MI:SS',
Input Timezone = 'Europe/Warsaw',
Output Timezone = 'UTC'.
I would like to create a solution that would allow me to swap e.g. Input Zone, something passed by parameter e.g. 'Europe/London'. I cannot rely on the system time unfortunately.
Good Morning All.
I have a comment field from an invoice system. The user goes into the invoice and leaves a comment/note on it. The source system tags each note with a date. However, the month is either a single digit or a double digit based on the date the note was entered same with the day. So the issue I am having is that I want to pull all of the invoice notes that start with a certain time period. So the notes always start like either one of these:
6/7/16 7:51 AM
11/11/16 8:11 PM
Is there a way to pull the date from the beginning of the note say using AM or PM as the starting point and working back to the beginning of the string?
What I can tell is that you might use Regular Expressions to extract the date from the string, but SQL server doesn't support the regular expression!
A work around is to use CLR, here an article that explain how to achieve what you want. Regular Expressions in MS SQL Server 2005/2008
To get some help on how to build the regular expression to match the dates, here another article that might help you : Regular Expression Library
The date regular expression could be ((\d{2})|(\d))\/((\d{2})|(\d))\/((\d{2})) ((\d{2})|(\d)):((\d{2})|(\d)) [AP]M
Hope this will help you
I have an issue with SSRS where when posting in a DD/MM/YY value via URL string into a Parameter it decides to read the Day value as the Year, the Month as month, but the Year goes into Day value, for example:
I am inputting the date of 30/08/17 via an ERP System which then generates a string to be used as an URL to generate the report, this date value should then go into a parameter called fiAsOfDate which is Date/Time data type, but at this point it is reading the value as 08/17/1930 inside the Parameter list, even though the URL remains at 30/08/17.
This happens prior to the Query being processed, and the fiAsOfDate parameter then gets formatted through to to MMDDYYYY to be processed within the Query, but the issue is specifically when the parameter is having the value loaded from the URL into the parameter value, and I was hoping if anyone could assist me on this please?
I should also add, this original date is coming from an ERP system which will have regional based date formatting, as it is used internationally, so I cannot restrict myself to one input format, and it should be using regional settings, matching that of the Reporting server that it is based on.
Kind Regards,
James W. Acklam.
To avoid regional setting issues you can change the date into a known integer or string format: I use CONVERT(NVARCHAR, YourDate, 112) to get a string '20170830'. The regional settings won't recognize that as a date and so won't auto-parse it into MM/DD/YYYY or DD/MM/YYYY. Of course, you'll need to parse that yourself so you can use it in the report, but at least you know the format.
This issue was down to my own misunderstanding that the DataSource I was pulling data from worked only in DMY format. Converting dates from parameters format to DMY format and processing that through the DataSet's query resolved the issue.
I have a VB6 application where I insert a set of dates into a SQL-SERVER. Each time I insert a value, it gets inserted as 1978-12-12 00:00:00.000. Is it possible to specify in the INSERT statement, how you want the date to be formatted? VB6 does not seem to recognize CONVERT. I did previously CONVERT date when I loaded it into a MSHFlexGrid like this:
Convert(varchar,tblClient.DOB, 101)
But I did this in a select statement. Will SQL let me insert a value in a format MM/DD/YYYY as I need it later in that format.
The reason why I need the formatting is because I connected all my tables in SQL-SERVER2008 to Access for report generating purposes. So I need it formatted correctly in SQL-SERVER2008 as it dynamically connects to Access.
Ideally, the data type of the column in the database is set to Date or DateTime. Basically, if you want to store a date, then use a date date type.
That being said, in VB6 you usually have to (at least temporarily) store the date as a string so there is almost always a string to date conversion that happens somewhere.
Will SQL let me insert a value in a format MM/DD/YYYY
Yes. But you should not do this. Instead, you should insert the date with the format "YYYYMMDD". Notice that there are no delimiters. The problem with mm/dd/yyyy is that it could accidentally be interpreted as the wrong date. For example, 1/2/2015 would be interpreted as Feb 1, 2015 if you lived in England, or Jan 2, 2015 if you live in the US. However, SQL Server will always interpret 20150102 and Jan 2, 2015.
Once you have the data stored the way you want in the database (as an actual date data type), you should actually return it as a date to your front end (either Access or VB6). In the front end, you should use the format command to display the date. The format command will use the regional settings of the computer to display dates the way the user wants to see it.
Ex:
txtDateOfBirth.Text = Format(rs.Fields.Item("DOB").value, "Short Date")
Doing things this way... you should never have problems with dates.
The best way is not to store formatted dates in your database server.
One way you can get what you want is by using a view where you format your data and use that as input for your report:
CREATE VIEW myreport
SELECT replace(convert(NVARCHAR, mydate, 106), ' ', '/') from mytable
But I would recommend formatting dates on the application level.
You can use VB6s format function prep the date before inserting it into SQL. Here's an example (tested in VBA).
Format(Now(), "YYYY-MM-DD")
I need to create a user defined Function that accepts a date input
and a date format input and results in a properly formatted date.
Ex: UDF('7/22', 'Internation')
OUTPUT: 22/7/2012
I need to implement all types of date formatting, or at least as much as possible. I think there should be at least 40 different types.
I've found solutions online that don't really work.
Does anyone have a function like this or can point me in the right direction. I'm pretty new to sql so writing this from scratch would take me until next week!