Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / DB Engine / SQL Server / July 2008

Tip: Looking for answers? Try searching our database.

Problem with Datetime when passed as paramater to stored procedure

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Ken - 21 Jul 2008 15:53 GMT
I am having a problem with a datetime when passed as a paramater in a
procedure.

To demonstrate the problem I have created a small procedure which
selects from a view which has a datetime column.

The select is made twice, once using the parameter in the where clause
and once using a copy of the paramater in the where clause

Each select is the same the dates are the same, but the number of
records returned are different (see result of execing procedure below)

Seems like a bug to me but I can not find any reference to it
anywhere.

I have worked around this problem using a second variable.

Anybody know what causes this??

----------------------------------------------------------o--
o----------------------------------------------------
Alter  Procedure DateTestProc (@ForDate DateTime = Null) As

Declare @OtherDate datetime
Declare @RowCount Numeric(38)

Select @ForDate = Convert(DateTime, '2008-07-31', 121)

Select @OtherDate = @ForDate

Print Convert(Varchar(32), @ForDate, 121)
Print Convert(Varchar(32), @OtherDate, 121)

Select
    @RowCount = Count(*)
From
    TestView
Where
    TestDate = @ForDate

Print @RowCount

Select
    @RowCount = Count(*)
From
    TestView
Where
    TestDate = @OtherDate

Print @RowCount

Go
----------------------------------------------------------o--
o----------------------------------------------------
Exec DateTestProc

----------------------------------------------------------o--
o----------------------------------------------------

2008-07-31 00:00:00.000
2008-07-31 00:00:00.000
259377
315204

----------------------------------------------------------o--
o----------------------------------------------------
Roy Harvey (SQL Server MVP) - 21 Jul 2008 16:30 GMT
The only thought that comes to mind is that something
non-deterministic is going on in TestView.

In your example @ForDate is passed as a parameter but the value passed
in is overwritten without being used.  Do you get the same result if
you comment out the assignment to @ForDate and pass the same date as a
parameter when the procedure is executed?

Roy Harvey
Beacon Falls, CT

>I am having a problem with a datetime when passed as a paramater in a
>procedure.
[quoted text clipped - 62 lines]
>----------------------------------------------------------o--
>o----------------------------------------------------
Ken - 21 Jul 2008 19:09 GMT
On Jul 21, 5:30 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:
> The only thought that comes to mind is that something
> non-deterministic is going on in TestView.
[quoted text clipped - 75 lines]
>
> - Show quoted text -

Nope...

The view just joins some tables. I can run the procedure any number of
times and get the same two different row counts.

Should also have mentioned that this is on SQLServer 2000 sp3
Roy Harvey (SQL Server MVP) - 21 Jul 2008 19:23 GMT
>> The only thought that comes to mind is that something
>> non-deterministic is going on in TestView.
[quoted text clipped - 3 lines]
>> you comment out the assignment to @ForDate and pass the same date as a
>> parameter when the procedure is executed?

>The view just joins some tables. I can run the procedure any number of
>times and get the same two different row counts.
>
>Should also have mentioned that this is on SQLServer 2000 sp3

I can't think of any way for that to happen.  Perhaps if you posted
the view, the table definitions and the query someone else will think
of something.

(You didn't say what happens when you actually use the date passed in
the parameter.)

Roy Harvey
Beacon Falls, CT
Ken - 22 Jul 2008 08:18 GMT
On Jul 21, 7:23 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:

> >> The only thought that comes to mind is that something
> >> non-deterministic is going on in TestView.
[quoted text clipped - 17 lines]
> Roy Harvey
> Beacon Falls, CT

The stored procedure demonstates the problem.

@ForDate is a parameter, which recieves a default null value, is then
modified to be '2008-07-31'.

@OtherDate is assigned the value of @ForDate, they are the same date.

The two selects are the same except that the where clause uses
different variables.

The view joins two static tables. The correct number of records for
the '2008-07-31' is 315204. This is the number of records returned
when the select is run interactively, or in any other way.

Only in the case of using the parameter variable @ForDate in the where
clause does the incorrect number of records.

The original version of this procedure seems to have worked for some
time. I am not sure that I can reproduce this problem in another
database (although it is reproduced in a restored copy of the original
database).

Unfortunately I may not post the schema for the view and underlying
tables.

It seems from the responses that this not occured before. We will
continue with the workaround of using a copy of the paramter variable.

Ken
Roy Harvey (SQL Server MVP) - 22 Jul 2008 16:30 GMT
>It seems from the responses that this not occured before.

Correct.  It makes no more sense to me than it does to you.

One question I should have asked in the first place.  WHICH OF THE TWO
COUNTS IS CORRECT????

Roy Harvey
Beacon Falls, CT
Ken - 22 Jul 2008 17:01 GMT
On Jul 22, 4:30 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:

> >It seems from the responses that this not occured before.
>
[quoted text clipped - 5 lines]
> Roy Harvey
> Beacon Falls, CT

315204 is the correct count (the second one). This is the number of
records returned when the date in the select clause is NOT using
@ForDate the procedure parameter.
Tom Cooper - 22 Jul 2008 17:24 GMT
My guess (and it's only a guess) is that there is something wrong with one
of your indexes. It may be that when using the stored proc parameter, the
Query Optimizer chooses a different plan than it does when you use a
variable that is not a parameter (due to parameter sniffing).  If that
different plan uses an index which for some reason is missing rows then you
could see this problem.

I would run either a DBCC CHECKDB to check the whole database or do a DBCC
CHECKTABLE  and DBCC CHECKALLOC on every table in your view to check the
tables in the view.  If finding the time to run the checks on your
production system is a problem, you could run the checks on a restored copy
of your database on another machine.

Tom

On Jul 21, 7:23 pm, "Roy Harvey (SQL Server MVP)"
<roy_har...@snet.net> wrote:
> On Mon, 21 Jul 2008 11:09:14 -0700 (PDT), Ken <ken.clo...@gmail.com>
> wrote:
[quoted text clipped - 20 lines]
> Roy Harvey
> Beacon Falls, CT

The stored procedure demonstates the problem.

@ForDate is a parameter, which recieves a default null value, is then
modified to be '2008-07-31'.

@OtherDate is assigned the value of @ForDate, they are the same date.

The two selects are the same except that the where clause uses
different variables.

The view joins two static tables. The correct number of records for
the '2008-07-31' is 315204. This is the number of records returned
when the select is run interactively, or in any other way.

Only in the case of using the parameter variable @ForDate in the where
clause does the incorrect number of records.

The original version of this procedure seems to have worked for some
time. I am not sure that I can reproduce this problem in another
database (although it is reproduced in a restored copy of the original
database).

Unfortunately I may not post the schema for the view and underlying
tables.

It seems from the responses that this not occured before. We will
continue with the workaround of using a copy of the paramter variable.

Ken
Ken - 24 Jul 2008 10:18 GMT
On Jul 22, 5:24 pm, "Tom Cooper"
<tomcoo...@comcast.no.spam.please.net> wrote:
> My guess (and it's only a guess) is that there is something wrong with one
> of your indexes. It may be that when using the stored proc parameter, the
[quoted text clipped - 70 lines]
>
> - Show quoted text -

Tom you have got to the root of the problem.

The DBCC checks  brought no errors, but when I turned on the actual
query plan in the management studio and the two variations have
slightly different plans (just a nested loop,which fails, instead of a
merge join which works).

So I syntactically rearranged the joins in the view from -- A join B
join C -- to -- A join C join B -- (the joins a semantically the same)
and the problem goes away (the plans are now completely different).

Next I rebuilt all the indexes, table a has 30 million rows with a
unique clustered index, table B and C have 15 thousand rows and each
has a unique clustered index. The joins are on the indexes, table A
being a superset of B and C.

Still no luck.

Ken
Tom Cooper - 25 Jul 2008 03:52 GMT
<snip>
> Tom you have got to the root of the problem.
>
[quoted text clipped - 15 lines]
>
> Ken

I'm mostly out of ideas.  Couple of other thoughts.

If the query plan that is not working uses parallelism, turn parallelism off
for this query (using query hint setting MAXDOP to 1).  There were known
bugs in parallel queries in SQL 2000 SP3.

You could also try restoring a backup of this database to a server with SQL
2000 SP4 and/or SQL 2005 and/or the prerelase version of SQL 2008 and see if
the problem goes away.  If it does, you can take that into your planning for
when/if you are going to move to either SP4 or SQL 2005 or SQL 2008 (when
that version is released).

You could try Microsoft support, but I don't know how much help that will be
since mainstream support for SQL 2000 ended April, 2008.

Tom
Ken - 25 Jul 2008 11:50 GMT
On Jul 25, 3:52 am, "Tom Cooper"
<tomcoo...@comcast.no.spam.please.net> wrote:
> <snip>
>
[quoted text clipped - 36 lines]
>
> - Show quoted text -

Tom

Happy Days

Sp4 fixes the problem... We had not applied it as we were anticipating
an upgrade to 2005.

(Ironically when I change  the  syntax of the query parallelism is
used and the problem is not apparent).

Thanks for your help.

Cheers,

Ken
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.