Checkpoints

Do I understand correctly that iIf I execute the CHECKPOINT statement from
query analyzer for a selected database, all uncommitted transactions in the
transaction log are physically written to the database at that time?
If so then do I need to manually truncate the log at another time to reduce
it's size. Because I'm assuming the CHECKPOINT does not automatically do
that.
Thanks for the clarification.No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to disk.
The "write-ahead log" (WAL) protocol used by SQL Server does not require
that all pages changed by a transaction are flushed to disk at the time of
the transaction commit; it only requires that the log records that affect
those transactions be persisted in the transaction log so that those
operations can be undone or redone in the case of a crash. The dirty pages
themselves can be written at the database system's lesiure. The number of
dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
interval) directly affects recovery time.
Books Online topic "CHECKPOINT" describes its function fairly well.
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
> Do I understand correctly that iIf I execute the CHECKPOINT statement from
> query analyzer for a selected database, all uncommitted transactions in
> the
> transaction log are physically written to the database at that time?
> If so then do I need to manually truncate the log at another time to
> reduce
> it's size. Because I'm assuming the CHECKPOINT does not automatically do
> that.
> Thanks for the clarification.|||Ryan,
Thanks very much... you're explanation makes it very clear!
"Ryan Stonecipher [MSFT]" wrote:

> No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to dis
k.
> The "write-ahead log" (WAL) protocol used by SQL Server does not require
> that all pages changed by a transaction are flushed to disk at the time of
> the transaction commit; it only requires that the log records that affect
> those transactions be persisted in the transaction log so that those
> operations can be undone or redone in the case of a crash. The dirty page
s
> themselves can be written at the database system's lesiure. The number of
> dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
> interval) directly affects recovery time.
> Books Online topic "CHECKPOINT" describes its function fairly well.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
> news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
>
>

Checkpoints

Do I understand correctly that iIf I execute the CHECKPOINT statement from
query analyzer for a selected database, all uncommitted transactions in the
transaction log are physically written to the database at that time?
If so then do I need to manually truncate the log at another time to reduce
it's size. Because I'm assuming the CHECKPOINT does not automatically do
that.
Thanks for the clarification.No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to disk.
The "write-ahead log" (WAL) protocol used by SQL Server does not require
that all pages changed by a transaction are flushed to disk at the time of
the transaction commit; it only requires that the log records that affect
those transactions be persisted in the transaction log so that those
operations can be undone or redone in the case of a crash. The dirty pages
themselves can be written at the database system's lesiure. The number of
dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
interval) directly affects recovery time.
Books Online topic "CHECKPOINT" describes its function fairly well.
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
> Do I understand correctly that iIf I execute the CHECKPOINT statement from
> query analyzer for a selected database, all uncommitted transactions in
> the
> transaction log are physically written to the database at that time?
> If so then do I need to manually truncate the log at another time to
> reduce
> it's size. Because I'm assuming the CHECKPOINT does not automatically do
> that.
> Thanks for the clarification.|||Ryan,
Thanks very much... you're explanation makes it very clear!
"Ryan Stonecipher [MSFT]" wrote:
> No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to disk.
> The "write-ahead log" (WAL) protocol used by SQL Server does not require
> that all pages changed by a transaction are flushed to disk at the time of
> the transaction commit; it only requires that the log records that affect
> those transactions be persisted in the transaction log so that those
> operations can be undone or redone in the case of a crash. The dirty pages
> themselves can be written at the database system's lesiure. The number of
> dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
> interval) directly affects recovery time.
> Books Online topic "CHECKPOINT" describes its function fairly well.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
> news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
> > Do I understand correctly that iIf I execute the CHECKPOINT statement from
> > query analyzer for a selected database, all uncommitted transactions in
> > the
> > transaction log are physically written to the database at that time?
> >
> > If so then do I need to manually truncate the log at another time to
> > reduce
> > it's size. Because I'm assuming the CHECKPOINT does not automatically do
> > that.
> >
> > Thanks for the clarification.
>
>

Checkpoints

Do I understand correctly that iIf I execute the CHECKPOINT statement from
query analyzer for a selected database, all uncommitted transactions in the
transaction log are physically written to the database at that time?
If so then do I need to manually truncate the log at another time to reduce
it's size. Because I'm assuming the CHECKPOINT does not automatically do
that.
Thanks for the clarification.
No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to disk.
The "write-ahead log" (WAL) protocol used by SQL Server does not require
that all pages changed by a transaction are flushed to disk at the time of
the transaction commit; it only requires that the log records that affect
those transactions be persisted in the transaction log so that those
operations can be undone or redone in the case of a crash. The dirty pages
themselves can be written at the database system's lesiure. The number of
dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
interval) directly affects recovery time.
Books Online topic "CHECKPOINT" describes its function fairly well.
Thanks,
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
> Do I understand correctly that iIf I execute the CHECKPOINT statement from
> query analyzer for a selected database, all uncommitted transactions in
> the
> transaction log are physically written to the database at that time?
> If so then do I need to manually truncate the log at another time to
> reduce
> it's size. Because I'm assuming the CHECKPOINT does not automatically do
> that.
> Thanks for the clarification.
|||Ryan,
Thanks very much... you're explanation makes it very clear!
"Ryan Stonecipher [MSFT]" wrote:

> No, it is CHECKPOINT's job to flush "dirty" (or changed) data pages to disk.
> The "write-ahead log" (WAL) protocol used by SQL Server does not require
> that all pages changed by a transaction are flushed to disk at the time of
> the transaction commit; it only requires that the log records that affect
> those transactions be persisted in the transaction log so that those
> operations can be undone or redone in the case of a crash. The dirty pages
> themselves can be written at the database system's lesiure. The number of
> dirty pages in memory at teh time of a crash (and therefore the CHECKPOINT
> interval) directly affects recovery time.
> Books Online topic "CHECKPOINT" describes its function fairly well.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Naj Parandah" <NajParandah@.discussions.microsoft.com> wrote in message
> news:18484540-E4E0-48FB-A2F0-472231705649@.microsoft.com...
>
>

Checking field within a selected record (**)

Hello,
I have sql statement that is selecting multiple invoice records and doing
multiple calculations.
Now, I need to look in each invoice record for Item_detail, any direction on
how I would do that would be appreciated?
Thanks.Hi
Can you post DDL+ sample data+ expected result?
"ITDUDE27" <ITDUDE27@.discussions.microsoft.com> wrote in message
news:976B69D5-44EA-43F9-A043-D9B9AAF4A83F@.microsoft.com...
> Hello,
> I have sql statement that is selecting multiple invoice records and doing
> multiple calculations.
> Now, I need to look in each invoice record for Item_detail, any direction
> on
> how I would do that would be appreciated?
> Thanks.|||is there a message board or something where we can put this as a disclaimer
:)|||That would be nice. Along with a post explaining how to return a
concatenated list of values for a single column in multiple rows, and a
"BEWARE OF --CELKO--" sign.
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
news:BE559B8C-7908-4E95-8C94-CAB986982C81@.microsoft.com...
> is there a message board or something where we can put this as a
disclaimer :)|||Oh come on... We all love Celko... LOL
Grant
Who gives a {censored} if I am wrong.
"Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
news:%23akCA2OeGHA.4276@.TK2MSFTNGP03.phx.gbl...
> That would be nice. Along with a post explaining how to return a
> concatenated list of values for a single column in multiple rows, and a
> "BEWARE OF --CELKO--" sign.
> "Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
> news:BE559B8C-7908-4E95-8C94-CAB986982C81@.microsoft.com...
> disclaimer :)
>|||of course we love him as long as we are not in the firing end :)
--
"Grant" wrote:

> Oh come on... We all love Celko... LOL
> --
> Grant
> Who gives a {censored} if I am wrong.
> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
> news:%23akCA2OeGHA.4276@.TK2MSFTNGP03.phx.gbl...
>
>|||Just to explain what is meant by DDL and sample data...
http://www.aspfaq.com/etiquette.asp?id=5006
"ITDUDE27" <ITDUDE27@.discussions.microsoft.com> wrote in message
news:976B69D5-44EA-43F9-A043-D9B9AAF4A83F@.microsoft.com...
> Hello,
> I have sql statement that is selecting multiple invoice records and doing
> multiple calculations.
> Now, I need to look in each invoice record for Item_detail, any direction
on
> how I would do that would be appreciated?
> Thanks.|||Did I ask for something peculiar?
I thought this was a helping board.
"Omnibuzz" wrote:
> of course we love him as long as we are not in the firing end :)
> --
>
>
> "Grant" wrote:
>|||Sorry, we got a little off topic, it happens sometimes. Nothign at all odd
for what you asked for, only that it was very vague, and we could give a
hundred answers, most of which would be completely unrelated to what you are
trying to do. You did not include enough information for us to give you a
good answer. Please see my other post and respond with the needed
information.
"ITDUDE27" <ITDUDE27@.discussions.microsoft.com> wrote in message
news:5B83C9D2-7A2C-46DD-B0DA-39D1B6483548@.microsoft.com...
> Did I ask for something peculiar?
> I thought this was a helping board.
> "Omnibuzz" wrote:
>
and a|||Oops.. sorry.. we thought we'll keep the thread alive till you get back with
the ddls and sample data.
--
"ITDUDE27" wrote:
> Did I ask for something peculiar?
> I thought this was a helping board.
> "Omnibuzz" wrote:
>

checkboxlist and SQL search using AND/OR on selected checkboxlist items.

I have a checkbox list like the one above. For example, Training OR Production – should include everyone with an Training OR everyone with a Production checked OR everyone with both Training and Production checked. If service AND technical support – just those two options will show – the customer can only have those 2 options selected in their account and nothing else. Is there an easy way to build the SQL query for this scenario? Any suggestions or tips?Thank you for any help

You can create a procedure that accepts a parameter ('AND' or 'OR), which perform a query based on the parameter:

create proc sp_testQuery @.logicOP varchar(3)='AND',@.id int,@.name varchar(20)
as
if @.logicOP='AND'
select * from t1 whereid=@.id and name=isnull(@.name,name)
else if @.logicOP='OR'
select * from t1 whereid=@.id orname=@.name
else raiserror('You must choose a logic operator ''AND'' or ''OR''',16,1)
go
sp_testQuery 'AND',1,null

Then what your code need to do is just call the stored procedure with providing all required parameters that come from your website.