StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2443613
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2010-03-14T20:22:26.057
FavoriteCount
0
LastActivityDate
2010-03-14T20:22:26.057
LastEditDate
LastEditorUserId
0
OwnerUserId
38360
ParentId
2442623
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
If the <code>MyDate</code> column is a <code>datetime</code>, as it appears to be, then it's already in the right "format". Don't convert it to a <code>varchar(50)</code> in the predicate condition - this makes your query non-sargable and will kill performance on any indexes you might have. Instead, take your parameters as <code>date</code> or <code>datetime</code> instances: <pre><code>SELECT ... FROM MyTable WHERE MyDate >= @BeginDate AND MyDate <= @EndDate </code></pre> Your query should not depend on a specific date format in the input parameters - those parameters are not <code>varchar</code> types, they are <code>datetime</code> (or <code>date</code>). When you run this query or stored procedure from whatever environment the application is in and supply binding parameters (you are using bind parameters, right?), said library will automatically handle any formatting issues. If you try to use the <code>>=</code> and <code><=</code> operators on character representations of dates, with any format other than the ISO standard <code>yyyymmdd</code>, you will get the wrong results, because the alphabetical order is different from the temporal order. Don't do this. If you simply need to write an ad-hoc query, i.e. this isn't being run from any programming environment, then simply do not use the <code>dd/mm/yyyy</code> format. Use the ISO date format instead; it is unambiguous and implicitly convertible to <code>datetime</code> values: <pre><code>SELECT ... FROM MyTable WHERE MyDate >= '20091231' AND MyDate <= '20100231' </code></pre> Honestly, no other solution is acceptable in my mind. For ad-hoc queries, always use the unambiguous ISO standard for dates. For applications connecting to the database, always use bind parameters. If you're doing anything else, you're writing code that's either unreliable, insecure, or both.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PONeed to find date's between 2 date's in SQL Server 2008
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAaronaught
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.