Showing posts with label rows. Show all posts
Showing posts with label rows. Show all posts

Monday, March 19, 2012

Date insert from VB.net problem

Hey there,

I'm trying to add rows to a table and pass a date value through. I use Format(Date.now, "dd MMM yyyy") however when I check in SQL Server Managment Studio it has swapped the day and month round (e.g. input of "7/9/2006" will be "9/7/2006" on the actual table. Actually the output is 2006-07-09 00:00:00:00.) I've put the full source code below.

Can anyone help with this?

Cheers,

Danny

Imports System.Data

Imports System.Data.SqlClient

Public Class Form1

Dim dtdate As Date

Dim cn As New SqlConnection("server=*********;database=********;USER ID=*********;password=*********")

Dim objCommand As New SqlCommand("", cn)

Dim ws As New wrtRefID.Service

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

dtdate = Now

AddHistory("ActivityID", 1, "AccountID", "AccountName", "ContactName", "Category", Microsoft.VisualBasic.Format(dtdate, "dd MMM yyyy"), 2, "Description", "UserName", Microsoft.VisualBasic.Format(dtdate, "dd MMM yyyy"), "CreateUser", "Notes", "LongNotes")

MessageBox.Show("DONE")

End Sub

Private Sub AddHistory(ByVal ActivityID As String, ByVal Type As Integer, ByVal AccountID As String, _

ByVal AccountName As String, ByVal ContactName As String, ByVal Category As String, ByVal StartDate As Date, _

ByVal Duration As Integer, ByVal Description As String, ByVal UserName As String, _

ByVal CreateDate As Date, ByVal CreateUser As String, ByVal Notes As String, ByVal LongNotes As String)

cn.Open()

objCommand.CommandText = "INSERT INTO HISTORY (HISTORYID, ACTIVITYID, Type, ACCOUNTID, ACCOUNTNAME, CONTACTNAME, " & _

"CATEGORY, STARTDATE, DURATION, DESCRIPTION, USERNAME, CREATEDATE, CREATEUSER, NOTES, LONGNOTES) " & _

"VALUES ('" & ws.MCS2_SLXID("HISTORY") & "', " & "'" & ActivityID & "', '" & Type & "', '" & AccountID & "', '" & AccountName & "', '" & ContactName & _

"', '" & Category & "', '" & StartDate & "', '" & Duration & "', '" & Description & "', '" & UserName & _

"', '" & CreateDate & "', '" & CreateUser & "', '" & Notes & "', '" & LongNotes & "')"

' MessageBox.Show(Format(dtdate, "dd MMM yyyy"))

TextBox1.Text = objCommand.CommandText

objCommand.ExecuteNonQuery()

cn.Close()

End Sub

End Class

Before explaining how to fix the date issue, it's important

to point out that your code may be vulnerable to a damaging

SQL injection attack. If the USER ID here has permission

to do more than insert rows into the table HISTORY, and if

you are not validating input in any way on the client side,

you are in trouble. A malicious user of your application

could enter into LongNotes, for example, a single quote

character followed by any SQL statement he or she wants to

run (like DELETE FROM HISTORY, or much worse, if this session

is opened by the sa account). See this article for more

information: www.sommarskog.se/dynamic_sql.html, or search

the web for "SQL injection."

Please, please, please, always use parameterized queries

or SQL stored procedures (and in the latter case, not

ones that just concatenate user input themselves).

You may be validating input on the client side or using

an account with limited privilege, in which case you should

at least add a comment in your code to note that this code

relies on security to be implemented elsewhere. However,

in my opinion, client-side-only security for this sort

of thing is not sufficient. Just to give one example,

some web sites will enforce what is typed into a form,

but overlook the fact that the form may not be the only

place to supply parameter values - direct specification

in the URL might be, too, and those values won't be

validated.

The best way to pass a date is through a parameterized

query or stored procedure, in which case you don't have

to use any format - you just pass it as a datetime value,

such as a SqlDateTime.

If you must pass your date as a string (and it's unlikely you

must, but it's a quicker, if more reckless, fix from what

you have now than to address the security and use parameters),

use the one date-only string format that SQL Server will

interpret consistently across culture settings: 'yyyymmdd'.

Be sure it's the string 'yyyymmdd', and not the integer yyyymmdd.

The only other safe format is the full datetime format

'YYYY-MM-DDTHH:MM:SS.mmm' (including the T character).

Vulnerable code like this is all too common, and I want

to say something whenever I see it.

Steve Kass

Drew University

http://www.stevekass.com

JediDanny@.discussions.microsoft.com wrote:

> This post has been edited either by the author or a moderator in the

> Microsoft Forums: http://forums.microsoft.com

>

> Hey there,

>

> I'm trying to add rows to a table and pass a date value through. I use

> Format(Date.now, "dd MMM yyyy") however when I check in SQL Server

> Managment Studio it has swapped the day and month round (e.g. input of

> "7/9/2006" will be "9/7/2006" on the actual table. Actually the output

> is 2006-07-09 00:00:00:00.) I've put the full source code below.

>

> Can anyone help with this?

>

> Cheers,

>

> Danny

>

>

>

> Imports System.Data

>

> Imports System.Data.SqlClient

>

> Public Class Form1

>

> Dim dtdate As Date

>

> Dim cn As New SqlConnection("server=*********;database=********;USER

> ID=*********;password=*********")

>

> Dim objCommand As New SqlCommand("", cn)

>

> Dim ws As New wrtRefID.Service

>

> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As

> System.EventArgs) Handles Button1.Click

>

> dtdate = Now

>

> AddHistory("ActivityID", 1, "AccountID", "AccountName", "ContactName",

> "Category", Microsoft.VisualBasic.Format(dtdate, "dd MMM yyyy"), 2,

> "Description", "UserName", Microsoft.VisualBasic.Format(dtdate, "dd MMM

> yyyy"), "CreateUser", "Notes", "LongNotes")

>

> MessageBox.Show("DONE")

>

> End Sub

>

> Private Sub AddHistory(ByVal ActivityID As String, ByVal Type As

> Integer, ByVal AccountID As String, _

>

> ByVal AccountName As String, ByVal ContactName As String, ByVal Category

> As String, ByVal StartDate As Date, _

>

> ByVal Duration As Integer, ByVal Description As String, ByVal UserName

> As String, _

>

> ByVal CreateDate As Date, ByVal CreateUser As String, ByVal Notes As

> String, ByVal LongNotes As String)

>

> cn.Open()

>

> objCommand.CommandText = "INSERT INTO HISTORY (HISTORYID, ACTIVITYID,

> Type, ACCOUNTID, ACCOUNTNAME, CONTACTNAME, " & _

>

> "CATEGORY, STARTDATE, DURATION, DESCRIPTION, USERNAME, CREATEDATE,

> CREATEUSER, NOTES, LONGNOTES) " & _

>

> "VALUES ('" & ws.MCS2_SLXID("HISTORY") & "', " & "'" & ActivityID & "',

> '" & Type & "', '" & AccountID & "', '" & AccountName & "', '" &

> ContactName & _

>

> "', '" & Category & "', '" & StartDate & "', '" & Duration & "', '" &

> Description & "', '" & UserName & _

>

> "', '" & CreateDate & "', '" & CreateUser & "', '" & Notes & "', '" &

> LongNotes & "')"

>

> ' MessageBox.Show(Format(dtdate, "dd MMM yyyy"))

>

> TextBox1.Text = objCommand.CommandText

>

> objCommand.ExecuteNonQuery()

>

> cn.Close()

>

> End Sub

>

> End Class

>

>

|||

It's doing exactly what you told it to do.

Your format string is saying day + month + year (ddMMyyyy) This is not wrong. You're reading it wrong.

If you want it to say month + day + year then write the format string thataway (MMddyyyy)

Adamus

|||

NNTP User wrote:

Before explaining how to fix the date issue, it's important

to point out that your code may be vulnerable to a damaging

SQL injection attack. If the USER ID here has permission

to do more than insert rows into the table HISTORY, and if

you are not validating input in any way on the client side,

you are in trouble. A malicious user of your application

could enter into LongNotes, for example, a single quote

character followed by any SQL statement he or she wants to

run (like DELETE FROM HISTORY, or much worse, if this session

is opened by the sa account). See this article for more

information: www.sommarskog.se/dynamic_sql.html, or search

the web for "SQL injection."

Please, please, please, always use parameterized queries

or SQL stored procedures (and in the latter case, not

ones that just concatenate user input themselves).

You may be validating input on the client side or using

an account with limited privilege, in which case you should

at least add a comment in your code to note that this code

relies on security to be implemented elsewhere. However,

in my opinion, client-side-only security for this sort

of thing is not sufficient. Just to give one example,

some web sites will enforce what is typed into a form,

but overlook the fact that the form may not be the only

place to supply parameter values - direct specification

in the URL might be, too, and those values won't be

validated.

The best way to pass a date is through a parameterized

query or stored procedure, in which case you don't have

to use any format - you just pass it as a datetime value,

such as a SqlDateTime.

If you must pass your date as a string (and it's unlikely you

must, but it's a quicker, if more reckless, fix from what

you have now than to address the security and use parameters),

use the one date-only string format that SQL Server will

interpret consistently across culture settings: 'yyyymmdd'.

Be sure it's the string 'yyyymmdd', and not the integer yyyymmdd.

The only other safe format is the full datetime format

'YYYY-MM-DDTHH:MM:SS.mmm' (including the T character).

Vulnerable code like this is all too common, and I want

to say something whenever I see it.

Steve Kass

Drew University

http://www.stevekass.com

JediDanny@.discussions.microsoft.com wrote:

> This post has been edited either by the author or a moderator in the

> Microsoft Forums: http://forums.microsoft.com

>

> Hey there,

>

> I'm trying to add rows to a table and pass a date value through. I use

> Format(Date.now, "dd MMM yyyy") however when I check in SQL Server

> Managment Studio it has swapped the day and month round (e.g. input of

> "7/9/2006" will be "9/7/2006" on the actual table. Actually the output

> is 2006-07-09 00:00:00:00.) I've put the full source code below.

>

> Can anyone help with this?

>

> Cheers,

>

> Danny

>

>

>

> Imports System.Data

>

> Imports System.Data.SqlClient

>

> Public Class Form1

>

> Dim dtdate As Date

>

> Dim cn As New SqlConnection("server=*********;database=********;USER

> ID=*********;password=*********")

>

> Dim objCommand As New SqlCommand("", cn)

>

> Dim ws As New wrtRefID.Service

>

> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As

> System.EventArgs) Handles Button1.Click

>

> dtdate = Now

>

> AddHistory("ActivityID", 1, "AccountID", "AccountName", "ContactName",

> "Category", Microsoft.VisualBasic.Format(dtdate, "dd MMM yyyy"), 2,

> "Description", "UserName", Microsoft.VisualBasic.Format(dtdate, "dd MMM

> yyyy"), "CreateUser", "Notes", "LongNotes")

>

> MessageBox.Show("DONE")

>

> End Sub

>

> Private Sub AddHistory(ByVal ActivityID As String, ByVal Type As

> Integer, ByVal AccountID As String, _

>

> ByVal AccountName As String, ByVal ContactName As String, ByVal Category

> As String, ByVal StartDate As Date, _

>

> ByVal Duration As Integer, ByVal Description As String, ByVal UserName

> As String, _

>

> ByVal CreateDate As Date, ByVal CreateUser As String, ByVal Notes As

> String, ByVal LongNotes As String)

>

> cn.Open()

>

> objCommand.CommandText = "INSERT INTO HISTORY (HISTORYID, ACTIVITYID,

> Type, ACCOUNTID, ACCOUNTNAME, CONTACTNAME, " & _

>

> "CATEGORY, STARTDATE, DURATION, DESCRIPTION, USERNAME, CREATEDATE,

> CREATEUSER, NOTES, LONGNOTES) " & _

>

> "VALUES ('" & ws.MCS2_SLXID("HISTORY") & "', " & "'" & ActivityID & "',

> '" & Type & "', '" & AccountID & "', '" & AccountName & "', '" &

> ContactName & _

>

> "', '" & Category & "', '" & StartDate & "', '" & Duration & "', '" &

> Description & "', '" & UserName & _

>

> "', '" & CreateDate & "', '" & CreateUser & "', '" & Notes & "', '" &

> LongNotes & "')"

>

> ' MessageBox.Show(Format(dtdate, "dd MMM yyyy"))

>

> TextBox1.Text = objCommand.CommandText

>

> objCommand.ExecuteNonQuery()

>

> cn.Close()

>

> End Sub

>

> End Class

>

>

WTF? lol|||

NNTP User wrote:

Before explaining how to fix the date issue, it's important

to point out that your code may be vulnerable to a damaging

SQL injection attack. If the USER ID here has permission

to do more than insert rows into the table HISTORY, and if

you are not validating input in any way on the client side,

you are in trouble. A malicious user of your application

could enter into LongNotes, for example, a single quote

character followed by any SQL statement he or she wants to

run (like DELETE FROM HISTORY, or much worse, if this session

is opened by the sa account). See this article for more

information: www.sommarskog.se/dynamic_sql.html, or search

the web for "SQL injection."

Please, please, please, always use parameterized queries

or SQL stored procedures (and in the latter case, not

ones that just concatenate user input themselves).

You may be validating input on the client side or using

an account with limited privilege, in which case you should

at least add a comment in your code to note that this code

relies on security to be implemented elsewhere. However,

in my opinion, client-side-only security for this sort

of thing is not sufficient. Just to give one example,

some web sites will enforce what is typed into a form,

but overlook the fact that the form may not be the only

place to supply parameter values - direct specification

in the URL might be, too, and those values won't be

validated.

The best way to pass a date is through a parameterized

query or stored procedure, in which case you don't have

to use any format - you just pass it as a datetime value,

such as a SqlDateTime.

If you must pass your date as a string (and it's unlikely you

must, but it's a quicker, if more reckless, fix from what

you have now than to address the security and use parameters),

use the one date-only string format that SQL Server will

interpret consistently across culture settings: 'yyyymmdd'.

Be sure it's the string 'yyyymmdd', and not the integer yyyymmdd.

The only other safe format is the full datetime format

'YYYY-MM-DDTHH:MM:SS.mmm' (including the T character).

Vulnerable code like this is all too common, and I want

to say something whenever I see it.

Steve Kass

Drew University

http://www.stevekass.com

JediDanny@.discussions.microsoft.com wrote:

> This post has been edited either by the author or a moderator in the

> Microsoft Forums: http://forums.microsoft.com

>

> Hey there,

>

> I'm trying to add rows to a table and pass a date value through. I use

> Format(Date.now, "dd MMM yyyy") however when I check in SQL Server

> Managment Studio it has swapped the day and month round (e.g. input of

> "7/9/2006" will be "9/7/2006" on the actual table. Actually the output

> is 2006-07-09 00:00:00:00.) I've put the full source code below.

>

> Can anyone help with this?

>

> Cheers,

>

> Danny

>

>

>

> Imports System.Data

>

> Imports System.Data.SqlClient

>

> Public Class Form1

>

> Dim dtdate As Date

>

> Dim cn As New SqlConnection("server=*********;database=********;USER

> ID=*********;password=*********")

>

> Dim objCommand As New SqlCommand("", cn)

>

> Dim ws As New wrtRefID.Service

>

> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As

> System.EventArgs) Handles Button1.Click

>

> dtdate = Now

>

> AddHistory("ActivityID", 1, "AccountID", "AccountName", "ContactName",

> "Category", Microsoft.VisualBasic.Format(dtdate, "dd MMM yyyy"), 2,

> "Description", "UserName", Microsoft.VisualBasic.Format(dtdate, "dd MMM

> yyyy"), "CreateUser", "Notes", "LongNotes")

>

> MessageBox.Show("DONE")

>

> End Sub

>

> Private Sub AddHistory(ByVal ActivityID As String, ByVal Type As

> Integer, ByVal AccountID As String, _

>

> ByVal AccountName As String, ByVal ContactName As String, ByVal Category

> As String, ByVal StartDate As Date, _

>

> ByVal Duration As Integer, ByVal Description As String, ByVal UserName

> As String, _

>

> ByVal CreateDate As Date, ByVal CreateUser As String, ByVal Notes As

> String, ByVal LongNotes As String)

>

> cn.Open()

>

> objCommand.CommandText = "INSERT INTO HISTORY (HISTORYID, ACTIVITYID,

> Type, ACCOUNTID, ACCOUNTNAME, CONTACTNAME, " & _

>

> "CATEGORY, STARTDATE, DURATION, DESCRIPTION, USERNAME, CREATEDATE,

> CREATEUSER, NOTES, LONGNOTES) " & _

>

> "VALUES ('" & ws.MCS2_SLXID("HISTORY") & "', " & "'" & ActivityID & "',

> '" & Type & "', '" & AccountID & "', '" & AccountName & "', '" &

> ContactName & _

>

> "', '" & Category & "', '" & StartDate & "', '" & Duration & "', '" &

> Description & "', '" & UserName & _

>

> "', '" & CreateDate & "', '" & CreateUser & "', '" & Notes & "', '" &

> LongNotes & "')"

>

> ' MessageBox.Show(Format(dtdate, "dd MMM yyyy"))

>

> TextBox1.Text = objCommand.CommandText

>

> objCommand.ExecuteNonQuery()

>

> cn.Close()

>

> End Sub

>

> End Class

>

>

Gotta lay off the crackpipe Steve.

Sunday, March 11, 2012

Date formatting

Is there a function to return the date in the format of "4 July 2007" instead. I am returning rows which contain dates in the format "20/07/2007 10:48:16". Is there any function that convert, or will I have to write the code myself? I dont mind writing the code, but its a friday evening, and I am lazy and tired :-)
You can get close enough with CONVERT

eg, convert(varchar, getdate(),106)

To get the full month name though i believe you'd have to write something bespoke.

HTH.
|||

Yes. You have to write your own..

Select Cast(day(getdate()) as Varchar)

+ ' '

+ datename(month, getdate())

+ ' '

+ Cast(year(getdate()) as varchar)

|||As Mani indicated, create your own function, pass in the date, and get it back just like you want it.

Thursday, March 8, 2012

Date format with SQL Server 2000

Hi,

I'm working with a table with more than 2 million rows. The problem is that the table has a field called "ShipDate" of type nvarchar. When I try to change the data type to DateTime sql server throws a data conversion error.

I noticed that the date format is as follow: 2006-10-23, so, is there a way sql server takes this field and change it using the field values and applying the correct format? meaning: 10/23/2006

thanks a lot

The mentioned value should be easily converted into a datetime column (2006-10-23). You seem to have corrupt data stored in the datecolumn. Try to get rid of it and prior identify it by using the following query:

SELECT Datecolumn
FROM SomeTable
WHERE ISDATE(Datecolumn) = 0

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Saturday, February 25, 2012

Date Filtering vs Row placement misbehaviour

I am using the classic Add Business Intelligence date dimension hierachy and getting correct results when I had my calendar hierachy on the rows expanded to the day level and my dimension calculations on the columns. The results were wrong when I moved the calendar hierachy to the filter area and selected one date.

In particular, the [Date].[Date Calculations].[Current Member Name] = [Date].[Reporting Calendar].CurrentMember.Name shows that when you filter the Hierachy down to the day, the Current Member is always incorrectly showing the week (in every cell). It is correct when filtered to all other higher levels than date (week, month...).

I have tested this on multiple date dimensions for some days now and it is very consistent. Also If you bring the Date Attribute Hieracy onto the rows, it jumps to the correct Current Member.

Anyone seen anything like this - filtering by a Hierachy member does not work at the lowest level (the day level) but it does work as a row heading? It may be related to the lowest level being the Dimension Key?

Weird.

See my post at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=517552&SiteID=1 with TOPCOUNT and many hierarchies. I am also getting inconsistent results.

Are we missing somehting when we set a 'conformed' hierarchy? I did not have the lowest level as the dimesion key. Then I set it to the DImension key for my 11 hierarchies in the Product dimension. It worked for a small sample data set and then it started failing when I introduced it to the main project with 10+ dimensions and many hierarchies.

Let me have your views on this.

|||

I looked at your issue. It is not obvious to me that the problem I had with .CurrentMember being wrong under a lowest level filter member is the same as your TOPCOUNT problem. I had to move my formulae out to a different dimension and put them on an attribute hierachy to work.

However, by lots of trial and error with the display of simple diagnostic formulae, it is likely that you can identify a key simple value that is not correct. We need more such simple problem examples because I am convinced there is a basic structural problem in the implimentation of MDX against UDM and it will show up as the wrong answer in many different circumstances.

Good luck with finding a structure where the formulae works - at least UDM had many choices.

|||

If you have defined date hierarchies such as Fiscal or calendar, have you ensured that the key element of the attributes used in the hierarchy is unique? You might have to use the key collection to define a combined key of Year, Quarter for the quarter in the attribute hierarchy.

I think that is why you maybe seeing the wrong results. I am looking through all my attribute hierarchies to ensure that I have these set-up correctly.

|||

I am using unique running integers as the key of the attributes in the hierachy.

Also I have repeated the problem in any other dimension hierachy where the lowest level used as a filter member causes the .Currentmember to get the incorrect value (it gets the parent member of the filter value)

So it seems to be an issue on even the simplest dimension hierachy when the formulae is added to a hierachy within the filter dimension. I fixed it by moving all the formulae out to a completely different dimension.

Date Filtering vs Row placement misbehaviour

I am using the classic Add Business Intelligence date dimension hierachy and getting correct results when I had my calendar hierachy on the rows expanded to the day level and my dimension calculations on the columns. The results were wrong when I moved the calendar hierachy to the filter area and selected one date.

In particular, the [Date].[Date Calculations].[Current Member Name] = [Date].[Reporting Calendar].CurrentMember.Name shows that when you filter the Hierachy down to the day, the Current Member is always incorrectly showing the week (in every cell). It is correct when filtered to all other higher levels than date (week, month...).

I have tested this on multiple date dimensions for some days now and it is very consistent. Also If you bring the Date Attribute Hieracy onto the rows, it jumps to the correct Current Member.

Anyone seen anything like this - filtering by a Hierachy member does not work at the lowest level (the day level) but it does work as a row heading? It may be related to the lowest level being the Dimension Key?

Weird.

See my post at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=517552&SiteID=1 with TOPCOUNT and many hierarchies. I am also getting inconsistent results.

Are we missing somehting when we set a 'conformed' hierarchy? I did not have the lowest level as the dimesion key. Then I set it to the DImension key for my 11 hierarchies in the Product dimension. It worked for a small sample data set and then it started failing when I introduced it to the main project with 10+ dimensions and many hierarchies.

Let me have your views on this.

|||

I looked at your issue. It is not obvious to me that the problem I had with .CurrentMember being wrong under a lowest level filter member is the same as your TOPCOUNT problem. I had to move my formulae out to a different dimension and put them on an attribute hierachy to work.

However, by lots of trial and error with the display of simple diagnostic formulae, it is likely that you can identify a key simple value that is not correct. We need more such simple problem examples because I am convinced there is a basic structural problem in the implimentation of MDX against UDM and it will show up as the wrong answer in many different circumstances.

Good luck with finding a structure where the formulae works - at least UDM had many choices.

|||

If you have defined date hierarchies such as Fiscal or calendar, have you ensured that the key element of the attributes used in the hierarchy is unique? You might have to use the key collection to define a combined key of Year, Quarter for the quarter in the attribute hierarchy.

I think that is why you maybe seeing the wrong results. I am looking through all my attribute hierarchies to ensure that I have these set-up correctly.

|||

I am using unique running integers as the key of the attributes in the hierachy.

Also I have repeated the problem in any other dimension hierachy where the lowest level used as a filter member causes the .Currentmember to get the incorrect value (it gets the parent member of the filter value)

So it seems to be an issue on even the simplest dimension hierachy when the formulae is added to a hierachy within the filter dimension. I fixed it by moving all the formulae out to a completely different dimension.

Friday, February 24, 2012

Date Datatype Oddity - Ref "Like"

While trying to resolve a very endepth data issue against
healthcare claims data (8 years = rows), have discovered
an oddity.
When I run a "LIKE '% %'" (two spaces) against a datetime
or smalldatetime data type field, all dates with days less
than 10 return.
Could someone explain, this resultset, since datetime is
actually stored has an equivalant to two 4 bit integers
(one for date and one for time)?
This occurs against SQL 2000 (6.5 compatability DB, 7.0
compatability DB, 2000 DB) and also against SQL 2005 Beta
2 (2005 DB).
John Whitehead
MSSQLDBA (9years)
John,
I think this will explain it:
select convert(varchar, convert(datetime, '20040930'))
--Sep 30 2004 12:00AM
select convert(varchar, convert(datetime, '20041001'))
--Oct 1 2004 12:00AM
Notice that the 1 for Oct 1 is left-padded with an extra space.
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
> When I run a "LIKE '% %'" (two spaces) against a datetime
> or smalldatetime data type field, all dates with days less
> than 10 return.
> Could someone explain, this resultset, since datetime is
> actually stored has an equivalant to two 4 bit integers
> (one for date and one for time)?
|||That's a very risky way to query datetime types. The default format varies
with your regional settings. Why are you querying like this? What are your
search criteria?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
While trying to resolve a very endepth data issue against
healthcare claims data (8 years = rows), have discovered
an oddity.
When I run a "LIKE '% %'" (two spaces) against a datetime
or smalldatetime data type field, all dates with days less
than 10 return.
Could someone explain, this resultset, since datetime is
actually stored has an equivalant to two 4 bit integers
(one for date and one for time)?
This occurs against SQL 2000 (6.5 compatability DB, 7.0
compatability DB, 2000 DB) and also against SQL 2005 Beta
2 (2005 DB).
John Whitehead
MSSQLDBA (9years)
|||You should never be using LIKE against a [SMALL]DATETIME column. However,
it is easy to explain why you are getting this error. Run this:
PRINT GETDATE()
It doesn't print the actual numeric values that are stored, it converts it
to a string first. The appearance of this string will vary depending on a
few things (locale, date format, language, etc). But the same conversion
happens behind the scenes when you apply a string function such as LIKE.
BTW, I can't reproduce your "only days with less than 10 days" scenario. I
am betting that you are converting to an explicit format, or you haven't
disclosed your complete where clause. Can you provide a full repro script?
http://www.aspfaq.com/
(Reverse address to reply.)
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
> While trying to resolve a very endepth data issue against
> healthcare claims data (8 years = rows), have discovered
> an oddity.
> When I run a "LIKE '% %'" (two spaces) against a datetime
> or smalldatetime data type field, all dates with days less
> than 10 return.
> Could someone explain, this resultset, since datetime is
> actually stored has an equivalant to two 4 bit integers
> (one for date and one for time)?
> This occurs against SQL 2000 (6.5 compatability DB, 7.0
> compatability DB, 2000 DB) and also against SQL 2005 Beta
> 2 (2005 DB).
>
> John Whitehead
> MSSQLDBA (9years)
|||Adam,
I would agree, however was not converting to a varchar
before the "like".
John

>--Original Message--
>John,
>I think this will explain it:
>select convert(varchar, convert(datetime, '20040930'))
>--Sep 30 2004 12:00AM
>
>select convert(varchar, convert(datetime, '20041001'))
>--Oct 1 2004 12:00AM
>
>Notice that the 1 for Oct 1 is left-padded with an extra
space.
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message[vbcol=seagreen]
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
datetime[vbcol=seagreen]
less
>
>.
>
|||Tom,
You are absolutely right, and this is in no way a normal
resolution discovery path. We had been working on this
issue for a while, and this path was taken due to the fact
that we import this data from a "~" delimited, fixed width
file (that we have no control over) and was looking at the
possibility of an special character somehow making it into
the database. Have found some very endepth information
about how the sqlserver engine handles data and was just
wondering if this oddity was caused by that process.
This is not an issue - just an oddity
Thanks
John

>--Original Message--
>That's a very risky way to query datetime types. The
default format varies
>with your regional settings. Why are you querying like
this? What are your
>search criteria?
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>While trying to resolve a very endepth data issue against
>healthcare claims data (8 years = rows), have discovered
>an oddity.
>When I run a "LIKE '% %'" (two spaces) against a datetime
>or smalldatetime data type field, all dates with days less
>than 10 return.
>Could someone explain, this resultset, since datetime is
>actually stored has an equivalant to two 4 bit integers
>(one for date and one for time)?
>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>compatability DB, 2000 DB) and also against SQL 2005 Beta
>2 (2005 DB).
>
>John Whitehead
>MSSQLDBA (9years)
>.
>
|||The conversion happens implictly because LIKE expects only string arguments.
David Portas
SQL Server MVP
|||> I would agree, however was not converting to a varchar
> before the "like".
You don't have to do it manually. LIKE is only relevant to string
arguments, and since [SMALL]DATETIME can be implicitly converted to VARCHAR,
that is what happens for you.
|||You may want to consider DTS to look for the bad data as it imports it.
Failing that, you could import the field from the flat file into a
char/varchar column and then search for anomalies via SQL against the
column. We'd have to know a bit more of what you are seeking.
Tom
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:254901c4a7e6$730376a0$a401280a@.phx.gbl...
Tom,
You are absolutely right, and this is in no way a normal
resolution discovery path. We had been working on this
issue for a while, and this path was taken due to the fact
that we import this data from a "~" delimited, fixed width
file (that we have no control over) and was looking at the
possibility of an special character somehow making it into
the database. Have found some very endepth information
about how the sqlserver engine handles data and was just
wondering if this oddity was caused by that process.
This is not an issue - just an oddity
Thanks
John

>--Original Message--
>That's a very risky way to query datetime types. The
default format varies
>with your regional settings. Why are you querying like
this? What are your
>search criteria?
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>While trying to resolve a very endepth data issue against
>healthcare claims data (8 years = rows), have discovered
>an oddity.
>When I run a "LIKE '% %'" (two spaces) against a datetime
>or smalldatetime data type field, all dates with days less
>than 10 return.
>Could someone explain, this resultset, since datetime is
>actually stored has an equivalant to two 4 bit integers
>(one for date and one for time)?
>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>compatability DB, 2000 DB) and also against SQL 2005 Beta
>2 (2005 DB).
>
>John Whitehead
>MSSQLDBA (9years)
>.
>
|||FINAL POST!!
This is the reason that I don't post to these boards!
THIS IS NOT AN ISSUE TO BE SOVLED - JUST AN ODDITY TO BE
EXPLAINED - "Confidentiality agreements prevent from
further explanations and process logic discussion"
Tom - I guarentee you that this is the first time in over
20 years of dealing with databases that I have run a LIKE
search against a date datatype. Some RDBMS's don't
allow "Like" against a date datatype.
Thanks Aaron, Logical, but is it a FACT, that the engine
would convert a numeric based data type to a character
base value in order to compare for the non-numeric "like"?
John

>--Original Message--
>You may want to consider DTS to look for the bad data as
it imports it.
>Failing that, you could import the field from the flat
file into a
>char/varchar column and then search for anomalies via SQL
against the
>column. We'd have to know a bit more of what you are
seeking.
> Tom
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message[vbcol=seagreen]
>news:254901c4a7e6$730376a0$a401280a@.phx.gbl...
>Tom,
>You are absolutely right, and this is in no way a normal
>resolution discovery path. We had been working on this
>issue for a while, and this path was taken due to the fact
>that we import this data from a "~" delimited, fixed width
>file (that we have no control over) and was looking at the
>possibility of an special character somehow making it into
>the database. Have found some very endepth information
>about how the sqlserver engine handles data and was just
>wondering if this oddity was caused by that process.
>This is not an issue - just an oddity
>Thanks
>John
>default format varies
>this? What are your
-[vbcol=seagreen]
>--
>in message
datetime[vbcol=seagreen]
less
>.
>

Date Datatype Oddity - Ref "Like"

While trying to resolve a very endepth data issue against
healthcare claims data (8 years = rows), have discovered
an oddity.
When I run a "LIKE '% %'" (two spaces) against a datetime
or smalldatetime data type field, all dates with days less
than 10 return.
Could someone explain, this resultset, since datetime is
actually stored has an equivalant to two 4 bit integers
(one for date and one for time)?
This occurs against SQL 2000 (6.5 compatability DB, 7.0
compatability DB, 2000 DB) and also against SQL 2005 Beta
2 (2005 DB).
John Whitehead
MSSQLDBA (9years)Sorry (8 years = rows) should read (8 years = 31 million
rows)
JohnW
>--Original Message--
>While trying to resolve a very endepth data issue against
>healthcare claims data (8 years = rows), have discovered
>an oddity.
>When I run a "LIKE '% %'" (two spaces) against a
datetime
>or smalldatetime data type field, all dates with days
less
>than 10 return.
>Could someone explain, this resultset, since datetime is
>actually stored has an equivalant to two 4 bit integers
>(one for date and one for time)?
>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>compatability DB, 2000 DB) and also against SQL 2005 Beta
>2 (2005 DB).
>
>John Whitehead
>MSSQLDBA (9years)
>.
>|||John,
I think this will explain it:
select convert(varchar, convert(datetime, '20040930'))
--Sep 30 2004 12:00AM
select convert(varchar, convert(datetime, '20041001'))
--Oct 1 2004 12:00AM
Notice that the 1 for Oct 1 is left-padded with an extra space.
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
> When I run a "LIKE '% %'" (two spaces) against a datetime
> or smalldatetime data type field, all dates with days less
> than 10 return.
> Could someone explain, this resultset, since datetime is
> actually stored has an equivalant to two 4 bit integers
> (one for date and one for time)?|||That's a very risky way to query datetime types. The default format varies
with your regional settings. Why are you querying like this? What are your
search criteria?
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
While trying to resolve a very endepth data issue against
healthcare claims data (8 years = rows), have discovered
an oddity.
When I run a "LIKE '% %'" (two spaces) against a datetime
or smalldatetime data type field, all dates with days less
than 10 return.
Could someone explain, this resultset, since datetime is
actually stored has an equivalant to two 4 bit integers
(one for date and one for time)?
This occurs against SQL 2000 (6.5 compatability DB, 7.0
compatability DB, 2000 DB) and also against SQL 2005 Beta
2 (2005 DB).
John Whitehead
MSSQLDBA (9years)|||You should never be using LIKE against a [SMALL]DATETIME column. However,
it is easy to explain why you are getting this error. Run this:
PRINT GETDATE()
It doesn't print the actual numeric values that are stored, it converts it
to a string first. The appearance of this string will vary depending on a
few things (locale, date format, language, etc). But the same conversion
happens behind the scenes when you apply a string function such as LIKE.
BTW, I can't reproduce your "only days with less than 10 days" scenario. I
am betting that you are converting to an explicit format, or you haven't
disclosed your complete where clause. Can you provide a full repro script?
--
http://www.aspfaq.com/
(Reverse address to reply.)
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
> While trying to resolve a very endepth data issue against
> healthcare claims data (8 years = rows), have discovered
> an oddity.
> When I run a "LIKE '% %'" (two spaces) against a datetime
> or smalldatetime data type field, all dates with days less
> than 10 return.
> Could someone explain, this resultset, since datetime is
> actually stored has an equivalant to two 4 bit integers
> (one for date and one for time)?
> This occurs against SQL 2000 (6.5 compatability DB, 7.0
> compatability DB, 2000 DB) and also against SQL 2005 Beta
> 2 (2005 DB).
>
> John Whitehead
> MSSQLDBA (9years)|||Adam,
I would agree, however was not converting to a varchar
before the "like".
John
>--Original Message--
>John,
>I think this will explain it:
>select convert(varchar, convert(datetime, '20040930'))
>--Sep 30 2004 12:00AM
>
>select convert(varchar, convert(datetime, '20041001'))
>--Oct 1 2004 12:00AM
>
>Notice that the 1 for Oct 1 is left-padded with an extra
space.
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>> When I run a "LIKE '% %'" (two spaces) against a
datetime
>> or smalldatetime data type field, all dates with days
less
>> than 10 return.
>> Could someone explain, this resultset, since datetime is
>> actually stored has an equivalant to two 4 bit integers
>> (one for date and one for time)?
>
>.
>|||Tom,
You are absolutely right, and this is in no way a normal
resolution discovery path. We had been working on this
issue for a while, and this path was taken due to the fact
that we import this data from a "~" delimited, fixed width
file (that we have no control over) and was looking at the
possibility of an special character somehow making it into
the database. Have found some very endepth information
about how the sqlserver engine handles data and was just
wondering if this oddity was caused by that process.
This is not an issue - just an oddity
Thanks
John
>--Original Message--
>That's a very risky way to query datetime types. The
default format varies
>with your regional settings. Why are you querying like
this? What are your
>search criteria?
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>While trying to resolve a very endepth data issue against
>healthcare claims data (8 years = rows), have discovered
>an oddity.
>When I run a "LIKE '% %'" (two spaces) against a datetime
>or smalldatetime data type field, all dates with days less
>than 10 return.
>Could someone explain, this resultset, since datetime is
>actually stored has an equivalant to two 4 bit integers
>(one for date and one for time)?
>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>compatability DB, 2000 DB) and also against SQL 2005 Beta
>2 (2005 DB).
>
>John Whitehead
>MSSQLDBA (9years)
>.
>|||The conversion happens implictly because LIKE expects only string arguments.
--
David Portas
SQL Server MVP
--|||> I would agree, however was not converting to a varchar
> before the "like".
You don't have to do it manually. LIKE is only relevant to string
arguments, and since [SMALL]DATETIME can be implicitly converted to VARCHAR,
that is what happens for you.|||You may want to consider DTS to look for the bad data as it imports it.
Failing that, you could import the field from the flat file into a
char/varchar column and then search for anomalies via SQL against the
column. We'd have to know a bit more of what you are seeking.
Tom
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com
"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:254901c4a7e6$730376a0$a401280a@.phx.gbl...
Tom,
You are absolutely right, and this is in no way a normal
resolution discovery path. We had been working on this
issue for a while, and this path was taken due to the fact
that we import this data from a "~" delimited, fixed width
file (that we have no control over) and was looking at the
possibility of an special character somehow making it into
the database. Have found some very endepth information
about how the sqlserver engine handles data and was just
wondering if this oddity was caused by that process.
This is not an issue - just an oddity
Thanks
John
>--Original Message--
>That's a very risky way to query datetime types. The
default format varies
>with your regional settings. Why are you querying like
this? What are your
>search criteria?
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>While trying to resolve a very endepth data issue against
>healthcare claims data (8 years = rows), have discovered
>an oddity.
>When I run a "LIKE '% %'" (two spaces) against a datetime
>or smalldatetime data type field, all dates with days less
>than 10 return.
>Could someone explain, this resultset, since datetime is
>actually stored has an equivalant to two 4 bit integers
>(one for date and one for time)?
>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>compatability DB, 2000 DB) and also against SQL 2005 Beta
>2 (2005 DB).
>
>John Whitehead
>MSSQLDBA (9years)
>.
>|||FINAL POST!!
This is the reason that I don't post to these boards!
THIS IS NOT AN ISSUE TO BE SOVLED - JUST AN ODDITY TO BE
EXPLAINED - "Confidentiality agreements prevent from
further explanations and process logic discussion"
Tom - I guarentee you that this is the first time in over
20 years of dealing with databases that I have run a LIKE
search against a date datatype. Some RDBMS's don't
allow "Like" against a date datatype.
Thanks Aaron, Logical, but is it a FACT, that the engine
would convert a numeric based data type to a character
base value in order to compare for the non-numeric "like"?
John
>--Original Message--
>You may want to consider DTS to look for the bad data as
it imports it.
>Failing that, you could import the field from the flat
file into a
>char/varchar column and then search for anomalies via SQL
against the
>column. We'd have to know a bit more of what you are
seeking.
> Tom
>--
>Tom
>----
--
>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>SQL Server MVP
>Columnist, SQL Server Professional
>Toronto, ON Canada
>www.pinnaclepublishing.com
>
>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
in message
>news:254901c4a7e6$730376a0$a401280a@.phx.gbl...
>Tom,
>You are absolutely right, and this is in no way a normal
>resolution discovery path. We had been working on this
>issue for a while, and this path was taken due to the fact
>that we import this data from a "~" delimited, fixed width
>file (that we have no control over) and was looking at the
>possibility of an special character somehow making it into
>the database. Have found some very endepth information
>about how the sqlserver engine handles data and was just
>wondering if this oddity was caused by that process.
>This is not an issue - just an oddity
>Thanks
>John
>>--Original Message--
>>That's a very risky way to query datetime types. The
>default format varies
>>with your regional settings. Why are you querying like
>this? What are your
>>search criteria?
>>--
>>Tom
>>----
-
>--
>>Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
>>SQL Server MVP
>>Columnist, SQL Server Professional
>>Toronto, ON Canada
>>www.pinnaclepublishing.com
>>
>>"John Whitehead" <jwhitehead@.thearksolutions.com> wrote
>in message
>>news:24d801c4a7df$bc939270$a401280a@.phx.gbl...
>>While trying to resolve a very endepth data issue against
>>healthcare claims data (8 years = rows), have discovered
>>an oddity.
>>When I run a "LIKE '% %'" (two spaces) against a
datetime
>>or smalldatetime data type field, all dates with days
less
>>than 10 return.
>>Could someone explain, this resultset, since datetime is
>>actually stored has an equivalant to two 4 bit integers
>>(one for date and one for time)?
>>This occurs against SQL 2000 (6.5 compatability DB, 7.0
>>compatability DB, 2000 DB) and also against SQL 2005 Beta
>>2 (2005 DB).
>>
>>John Whitehead
>>MSSQLDBA (9years)
>>.
>.
>|||"John Whitehead" <jwhitehead@.thearksolutions.com> wrote in message
news:25f401c4a7ee$c91e7cd0$a401280a@.phx.gbl...
> This is the reason that I don't post to these boards!
It's free support... Sometimes you get what you pay for, other times
you get quite a bit more :-)
> Thanks Aaron, Logical, but is it a FACT, that the engine
> would convert a numeric based data type to a character
> base value in order to compare for the non-numeric "like"?
Yes, that's the only way the LIKE operator can work.|||> This is the reason that I don't post to these boards!
> THIS IS NOT AN ISSUE TO BE SOVLED - JUST AN ODDITY TO BE
> EXPLAINED
You got that, and more. Don't look a gift horse in the mouth.
> Thanks Aaron, Logical, but is it a FACT, that the engine
> would convert a numeric based data type to a character
> base value in order to compare for the non-numeric "like"?
Nah, I made it all up. *shrug*|||> BTW, I can't reproduce your "only days with less than 10 days" scenario.
> I
> am betting that you are converting to an explicit format, or you haven't
> disclosed your complete where clause. Can you provide a full repro
> script?
Aaron :
I'm not related to the original poster, I was just lurking, but here it is :
Create Table TableX
(ColX SmallDateTime Not Null )
Insert Into TableX Values ('20041101')
Insert Into TableX Values ('20041102')
Insert Into TableX Values ('20041109')
Insert Into TableX Values ('20041110')
Insert Into TableX Values ('20041111')
Insert Into TableX Values ('20041001')
Insert Into TableX Values ('20041002')
Insert Into TableX Values ('20041009')
Insert Into TableX Values ('20041010')
Insert Into TableX Values ('20041011')
Select * From TableX Where ColX Like '% %'
-- or Select * From TableX Where Cast(ColX as VarChar(20)) Like '% %'
Output in SQL Analyzer :
2004-11-01 00:00:00
2004-11-02 00:00:00
2004-11-09 00:00:00
2004-10-01 00:00:00
2004-10-02 00:00:00
2004-10-09 00:00:00
I have yyyy-mm-dd in my regional settings.
Regards,|||Sorry, I missed the two spaces in the original post, I thought there was
only one.
Regardless, the rest of the thread shows why this is a bad idea in the first
place.
--
http://www.aspfaq.com/
(Reverse address to reply.)
"Craig Kenisston" <craigkenisston@.hotmail.com> wrote in message
news:#znUhsAqEHA.1164@.TK2MSFTNGP10.phx.gbl...
> > BTW, I can't reproduce your "only days with less than 10 days" scenario.
> > I
> > am betting that you are converting to an explicit format, or you haven't
> > disclosed your complete where clause. Can you provide a full repro
> > script?
> Aaron :
> I'm not related to the original poster, I was just lurking, but here it is
:
> Create Table TableX
> (ColX SmallDateTime Not Null )
> Insert Into TableX Values ('20041101')
> Insert Into TableX Values ('20041102')
> Insert Into TableX Values ('20041109')
> Insert Into TableX Values ('20041110')
> Insert Into TableX Values ('20041111')
> Insert Into TableX Values ('20041001')
> Insert Into TableX Values ('20041002')
> Insert Into TableX Values ('20041009')
> Insert Into TableX Values ('20041010')
> Insert Into TableX Values ('20041011')
> Select * From TableX Where ColX Like '% %'
> -- or Select * From TableX Where Cast(ColX as VarChar(20)) Like '% %'
> Output in SQL Analyzer :
> 2004-11-01 00:00:00
> 2004-11-02 00:00:00
> 2004-11-09 00:00:00
> 2004-10-01 00:00:00
> 2004-10-02 00:00:00
> 2004-10-09 00:00:00
> I have yyyy-mm-dd in my regional settings.
> Regards,
>

Friday, February 17, 2012

date comparison

I'm trying to filter rows to a datetime column as it matches to a datetime
column in another table. For example:
For Each irow In dsbnlsum.Tables(0).Select("inv_dt between '" &
(irowd("inv_dt") - 1) & Chr(39) & " and '" & (irowd("inv_dt") + 1) &
Chr(39))
(Developed in vb .net, but a basic question for sql server as well.)
Note that I took a datetime column in a table represented by irowd and
overlapped it, so that my datetime column (inv_dt) would be inside the
range. I'm not even sure this will work, but is there a better way? FYI -
inv_dt is often created as Now, so it could be 8/22/2002 5:16pm or
03/18/2001 12:02am, etc.
Tx for any help.
Bernie YaegerSearch SQL books on line for 'Date and Time Functions' also SQL uses BETWEEN
if you wish to search for a date with a range. eg:-
Select * from table where DateColumn between '20031007 13:27' AND GetDate()
HTH
Ryan Waight, MCDBA, MCSE
"Bernie Yaeger" <berniey@.cherwellinc.com> wrote in message
news:DZygb.60405$E95.31061722@.news4.srv.hcvlny.cv.net...
> I'm trying to filter rows to a datetime column as it matches to a datetime
> column in another table. For example:
> For Each irow In dsbnlsum.Tables(0).Select("inv_dt between '" &
> (irowd("inv_dt") - 1) & Chr(39) & " and '" & (irowd("inv_dt") + 1) &
> Chr(39))
> (Developed in vb .net, but a basic question for sql server as well.)
> Note that I took a datetime column in a table represented by irowd and
> overlapped it, so that my datetime column (inv_dt) would be inside the
> range. I'm not even sure this will work, but is there a better way?
FYI -
> inv_dt is often created as Now, so it could be 8/22/2002 5:16pm or
> 03/18/2001 12:02am, etc.
> Tx for any help.
> Bernie Yaeger
>