EXEC WITH RECOMPILE

Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
LeilaThat's the way it works. Consider an EXEC WITH RECOMPILE to be an
"exception" - a one-time use of the plan. If you want a "permanent' new
plan, check out sp_recompile in the BOL.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
Leila|||Per Books Online:
RECOMPILE
Indicates that the Database Engine does not cache a plan for this procedure
and the procedure is compiled at run time. This option cannot be used when
FOR REPLICATION is specified. RECOMPILE cannot be specified for CLR stored
procedures.
To instruct the Database Engine to discard plans for individual queries
inside a stored procedure, use the RECOMPILE query hint. For more
information, see Query Hint (Transact-SQL). Use the RECOMPILE query hint whe
n
atypical or temporary values are used in only a subset of queries that belon
g
to the stored procedure.
"Leila" wrote:

> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>
>|||"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
A quick experiments with BOL confirms your findings:
WITH RECOMPILE
Forces a new plan to be compiled, used, and discarded after the module is
executed. If there is an existing query plan for the module, this plan
remains in the cache.
Use this option if the parameter you are supplying is atypical or if the
data has significantly changed. This option is not used for extended stored
procedures. We recommend that you use this option sparingly because it is
expensive.
David|||Thanks every body :-)
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23YCk3t0VGHA.2760@.TK2MSFTNGP11.phx.gbl...
> That's the way it works. Consider an EXEC WITH RECOMPILE to be an
> "exception" - a one-time use of the plan. If you want a "permanent' new
> plan, check out sp_recompile in the BOL.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>

EXEC WITH RECOMPILE

Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
LeilaThat's the way it works. Consider an EXEC WITH RECOMPILE to be an
"exception" - a one-time use of the plan. If you want a "permanent' new
plan, check out sp_recompile in the BOL.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
Leila|||Per Books Online:
RECOMPILE
Indicates that the Database Engine does not cache a plan for this procedure
and the procedure is compiled at run time. This option cannot be used when
FOR REPLICATION is specified. RECOMPILE cannot be specified for CLR stored
procedures.
To instruct the Database Engine to discard plans for individual queries
inside a stored procedure, use the RECOMPILE query hint. For more
information, see Query Hint (Transact-SQL). Use the RECOMPILE query hint whe
n
atypical or temporary values are used in only a subset of queries that belon
g
to the stored procedure.
"Leila" wrote:

> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>
>|||"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
A quick experiments with BOL confirms your findings:
WITH RECOMPILE
Forces a new plan to be compiled, used, and discarded after the module is
executed. If there is an existing query plan for the module, this plan
remains in the cache.
Use this option if the parameter you are supplying is atypical or if the
data has significantly changed. This option is not used for extended stored
procedures. We recommend that you use this option sparingly because it is
expensive.
David|||Thanks every body :-)
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23YCk3t0VGHA.2760@.TK2MSFTNGP11.phx.gbl...
> That's the way it works. Consider an EXEC WITH RECOMPILE to be an
> "exception" - a one-time use of the plan. If you want a "permanent' new
> plan, check out sp_recompile in the BOL.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>

EXEC WITH RECOMPILE

Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
Leila
That's the way it works. Consider an EXEC WITH RECOMPILE to be an
"exception" - a one-time use of the plan. If you want a "permanent' new
plan, check out sp_recompile in the BOL.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
..
"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
Leila
|||Per Books Online:
RECOMPILE
Indicates that the Database Engine does not cache a plan for this procedure
and the procedure is compiled at run time. This option cannot be used when
FOR REPLICATION is specified. RECOMPILE cannot be specified for CLR stored
procedures.
To instruct the Database Engine to discard plans for individual queries
inside a stored procedure, use the RECOMPILE query hint. For more
information, see Query Hint (Transact-SQL). Use the RECOMPILE query hint when
atypical or temporary values are used in only a subset of queries that belong
to the stored procedure.
"Leila" wrote:

> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>
>
|||"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
A quick experiments with BOL confirms your findings:
WITH RECOMPILE
Forces a new plan to be compiled, used, and discarded after the module is
executed. If there is an existing query plan for the module, this plan
remains in the cache.
Use this option if the parameter you are supplying is atypical or if the
data has significantly changed. This option is not used for extended stored
procedures. We recommend that you use this option sparingly because it is
expensive.
David
|||Thanks every body :-)
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23YCk3t0VGHA.2760@.TK2MSFTNGP11.phx.gbl...
> That's the way it works. Consider an EXEC WITH RECOMPILE to be an
> "exception" - a one-time use of the plan. If you want a "permanent' new
> plan, check out sp_recompile in the BOL.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>

EXEC WITH RECOMPILE

Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
LeilaThat's the way it works. Consider an EXEC WITH RECOMPILE to be an
"exception" - a one-time use of the plan. If you want a "permanent' new
plan, check out sp_recompile in the BOL.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
Hi,
It seems that when you execute an SP along with WITH RECOMPILE option, the
SP is recompiled for that particular execution (only) and the old plan is
not replaced with new one in ProcCache. Is it correct or there's something
wrong with my experimentations?!
Thanks in advance,
Leila|||Per Books Online:
RECOMPILE
Indicates that the Database Engine does not cache a plan for this procedure
and the procedure is compiled at run time. This option cannot be used when
FOR REPLICATION is specified. RECOMPILE cannot be specified for CLR stored
procedures.
To instruct the Database Engine to discard plans for individual queries
inside a stored procedure, use the RECOMPILE query hint. For more
information, see Query Hint (Transact-SQL). Use the RECOMPILE query hint when
atypical or temporary values are used in only a subset of queries that belong
to the stored procedure.
"Leila" wrote:
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>
>|||"Leila" <Leilas@.hotpop.com> wrote in message
news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
A quick experiments with BOL confirms your findings:
WITH RECOMPILE
Forces a new plan to be compiled, used, and discarded after the module is
executed. If there is an existing query plan for the module, this plan
remains in the cache.
Use this option if the parameter you are supplying is atypical or if the
data has significantly changed. This option is not used for extended stored
procedures. We recommend that you use this option sparingly because it is
expensive.
David|||Thanks every body :-)
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23YCk3t0VGHA.2760@.TK2MSFTNGP11.phx.gbl...
> That's the way it works. Consider an EXEC WITH RECOMPILE to be an
> "exception" - a one-time use of the plan. If you want a "permanent' new
> plan, check out sp_recompile in the BOL.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "Leila" <Leilas@.hotpop.com> wrote in message
> news:u6K4wp0VGHA.1204@.TK2MSFTNGP12.phx.gbl...
> Hi,
> It seems that when you execute an SP along with WITH RECOMPILE option, the
> SP is recompiled for that particular execution (only) and the old plan is
> not replaced with new one in ProcCache. Is it correct or there's something
> wrong with my experimentations?!
> Thanks in advance,
> Leila
>

Excesive Space Allocated

Hello,
I have a fairly large database that at one time I used to do a lot of processing on. Now it's nothing but backup for some old data. I've truncated my transaction log and it's down to about 25 megs. The problem is the transaction log is allocated for ar
ound 2.5 gigs and I can't get it to allocated any less so I'm waiting a ton of space on my server. Is there anyway to shrink how much size your allocated for your log file?
Thanks
Check out DBCC SHRINKFILE in BOL.
Andrew J. Kelly SQL MVP
"Chuck" <anonymous@.discussions.microsoft.com> wrote in message
news:9DF0AAF1-1776-4C66-BE74-EE649A3F7CFE@.microsoft.com...
> Hello,
> I have a fairly large database that at one time I used to do a lot of
processing on. Now it's nothing but backup for some old data. I've
truncated my transaction log and it's down to about 25 megs. The problem is
the transaction log is allocated for around 2.5 gigs and I can't get it to
allocated any less so I'm waiting a ton of space on my server. Is there
anyway to shrink how much size your allocated for your log file?
> Thanks

Excesive Space Allocated

Hello,
I have a fairly large database that at one time I used to do a lot of proces
sing on. Now it's nothing but backup for some old data. I've truncated my
transaction log and it's down to about 25 megs. The problem is the transact
ion log is allocated for ar
ound 2.5 gigs and I can't get it to allocated any less so I'm waiting a ton
of space on my server. Is there anyway to shrink how much size your allocat
ed for your log file?
ThanksCheck out DBCC SHRINKFILE in BOL.
Andrew J. Kelly SQL MVP
"Chuck" <anonymous@.discussions.microsoft.com> wrote in message
news:9DF0AAF1-1776-4C66-BE74-EE649A3F7CFE@.microsoft.com...
> Hello,
> I have a fairly large database that at one time I used to do a lot of
processing on. Now it's nothing but backup for some old data. I've
truncated my transaction log and it's down to about 25 megs. The problem is
the transaction log is allocated for around 2.5 gigs and I can't get it to
allocated any less so I'm waiting a ton of space on my server. Is there
anyway to shrink how much size your allocated for your log file?
> Thanks

Excel XP and SQL Server... a good match?

Suppose I have an appliation made in VB6 which connects to SQL2000.
The applications creates a DSN(old style) to connecto to the server.
The user has a login an a password to use the application. The server
validades Windows NT login.
Every effort had been made to protect the database from intruders.
So far so good...
Next day, comes Clarck Kent and connects to the server simply by using the DSN
and Excel 2000!!! He can browse, update and delete files!!!
How can I avoid such intruder.
Thank you... waitng for replies...
Rick
use stored procedures and validate within the procedures with app_name()
http://sqlservercode.blogspot.com/
"Rick" wrote:

> Suppose I have an appliation made in VB6 which connects to SQL2000.
> The applications creates a DSN(old style) to connecto to the server.
> The user has a login an a password to use the application. The server
> validades Windows NT login.
> Every effort had been made to protect the database from intruders.
> So far so good...
> Next day, comes Clarck Kent and connects to the server simply by using the DSN
> and Excel 2000!!! He can browse, update and delete files!!!
> How can I avoid such intruder.
> Thank you... waitng for replies...
> --
> Rick
|||On Wed, 21 Sep 2005 12:20:08 -0700, "Rick"
<Rick@.discussions.microsoft.com> wrote:
>Next day, comes Clarck Kent and connects to the server simply by using the DSN
>and Excel 2000!!! He can browse, update and delete files!!!
>How can I avoid such intruder.
See "application roles" in BOL.
In other words, grant only limited and/or read access to the Windows
login, require another user or application login for updates and such.
J.

Excel XP and SQL Server... a good match?

Suppose I have an appliation made in VB6 which connects to SQL2000.
The applications creates a DSN(old style) to connecto to the server.
The user has a login an a password to use the application. The server
validades Windows NT login.
Every effort had been made to protect the database from intruders.
So far so good...
Next day, comes Clarck Kent and connects to the server simply by using the D
SN
and Excel 2000!!! He can browse, update and delete files!!!
How can I avoid such intruder.
Thank you... waitng for replies...
Rickuse stored procedures and validate within the procedures with app_name()
http://sqlservercode.blogspot.com/
"Rick" wrote:

> Suppose I have an appliation made in VB6 which connects to SQL2000.
> The applications creates a DSN(old style) to connecto to the server.
> The user has a login an a password to use the application. The server
> validades Windows NT login.
> Every effort had been made to protect the database from intruders.
> So far so good...
> Next day, comes Clarck Kent and connects to the server simply by using the
DSN
> and Excel 2000!!! He can browse, update and delete files!!!
> How can I avoid such intruder.
> Thank you... waitng for replies...
> --
> Rick|||On Wed, 21 Sep 2005 12:20:08 -0700, "Rick"
<Rick@.discussions.microsoft.com> wrote:
>Next day, comes Clarck Kent and connects to the server simply by using the
DSN
>and Excel 2000!!! He can browse, update and delete files!!!
>How can I avoid such intruder.
See "application roles" in BOL.
In other words, grant only limited and/or read access to the Windows
login, require another user or application login for updates and such.
J.

Excel XP and SQL Server... a good match?

Suppose I have an appliation made in VB6 which connects to SQL2000.
The applications creates a DSN(old style) to connecto to the server.
The user has a login an a password to use the application. The server
validades Windows NT login.
Every effort had been made to protect the database from intruders.
So far so good...
Next day, comes Clarck Kent and connects to the server simply by using the DSN
and Excel 2000!!! He can browse, update and delete files!!!
How can I avoid such intruder.
Thank you... waitng for replies...
--
Rickuse stored procedures and validate within the procedures with app_name()
http://sqlservercode.blogspot.com/
"Rick" wrote:
> Suppose I have an appliation made in VB6 which connects to SQL2000.
> The applications creates a DSN(old style) to connecto to the server.
> The user has a login an a password to use the application. The server
> validades Windows NT login.
> Every effort had been made to protect the database from intruders.
> So far so good...
> Next day, comes Clarck Kent and connects to the server simply by using the DSN
> and Excel 2000!!! He can browse, update and delete files!!!
> How can I avoid such intruder.
> Thank you... waitng for replies...
> --
> Rick|||On Wed, 21 Sep 2005 12:20:08 -0700, "Rick"
<Rick@.discussions.microsoft.com> wrote:
>Next day, comes Clarck Kent and connects to the server simply by using the DSN
>and Excel 2000!!! He can browse, update and delete files!!!
>How can I avoid such intruder.
See "application roles" in BOL.
In other words, grant only limited and/or read access to the Windows
login, require another user or application login for updates and such.
J.