cursor in Stored Procedures

any one Explain me the details about Cursors in Stored Procedures and is there any other way to call views in stored Procedure

Quote:

Originally Posted by hariharanmca

any one Explain me the details about Cursors in Stored Procedures and is there any other way to call views in stored Procedure

Its very Urgent, If i simply write select * from vw_viewName then its giving Error like

Error:
=================================
Server: Msg 8624, Level 16, State 16, Procedure sp_Add_Remove_ItemQtyForNonChargeOrder , Line 18
Internal SQL Server error.

Line 18 is select * from vw_viewName|||See problem description here.

Current date Prior year date

In details two seperate formulas for date (current range ie: 4/1/06 to 4/30/06), second formula for prior year same month and day range. Grouping is daily.
The formulas work but are seperated by range not picked. How do I get the date ranges side by side for comparison. I am not using cross-tab.
Any help always appreciated.

ok, after starting from square one I finally have the data I was looking for but....
formatting and suppression not doing as I had hoped.
The report looks like this:

Column1 Column2 Column3 Column4 Column5
Current date data data Prior Year data
4/1/05: Fri 200
4/2/05: Sat 47
4/1/06: Sat 247
4/3/06: Mon 30

How do I get these to line up in the same row without subreports?
I have suppressed everything I can think of...

HelpCan you post some sample data and the result you want?

Current Activity : Locks/Object : DB Level locks.

The Current Activity monitor (Locks/Object) shows a number of processes that
have obtained a database level lock.
Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
What causes these db level locks?
All are SHARED level locks - and the status for is GRANT - meaning that the
lock has been successfully obtained.
How can I prevent these locks from appearing?
Cheers!
SQLCatZHi
Every connection will acquire a DB level lock when the connection is
established, to the database specified in the connection string from the
client..
This enables SQL Server to do a very fast lookup to see if a DB is in use
(for auto close, detach, drop database etc).
It is a shared lock.
You can not set this.
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:DA43536F-E52A-4D1A-AB83-6433FEA6D1BD@.microsoft.com...
> The Current Activity monitor (Locks/Object) shows a number of processes
> that
> have obtained a database level lock.
> Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
> What causes these db level locks?
> All are SHARED level locks - and the status for is GRANT - meaning that
> the
> lock has been successfully obtained.
> How can I prevent these locks from appearing?
> Cheers!
> SQLCatZ
>
>|||Hello Mike,
If the connection is established only to check on the status of the db -
then it should be a for a very short duration. The entry for this kind of
lock should appear and then disappear from the 'Current Activity :
Locks/Object' view. It should not persist for hours on end.
What should I look out for in the design/code that is creating these
multiple db level locks to persist for extended periods of time.
Thank you.
SQLCatZ|||Hi
The client connection, as long as it is open, holds the DB Shared Lock (SQL
Server does it on it's behalf).
There is nothing wrong with those locks, and at most, there could be 32'737
of them if all connections are used that SQL Server supports.
It is a small number compared to the locks required my most SELECT and
UPDATE operations.
The application should also be looked at. The principle of "Acquire Late,
Release Early" should always be applied. An application should not open a
connection and hold it open until it gets closed, rather, it should open the
connection, do it's query, and close the connection again. Connection
pooling will negate any performance problems related to establishing and
tearing down connections in short intervals.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:98FF664C-472A-4A50-B383-719E37F10BFE@.microsoft.com...
> Hello Mike,
> If the connection is established only to check on the status of the db -
> then it should be a for a very short duration. The entry for this kind of
> lock should appear and then disappear from the 'Current Activity :
> Locks/Object' view. It should not persist for hours on end.
> What should I look out for in the design/code that is creating these
> multiple db level locks to persist for extended periods of time.
> Thank you.
> SQLCatZ
>
>|||Hello Mike,
Thank you!
Your reply cleared things up.
I was aware of the "Acquire Late, Release Early" principle - but felt very
very uncomfortable when I saw a bunch of DB level locks hanging around for
extended periods of time.
Cheers!
SQLCatZ|||Basically Db locks prevent anyone from doing RESTORE and DROP DATABASE. When
MS looked into how
prohibiting these actions for 7.0, they realized that using the already pres
ent lock handing would
be a clean way of doing it.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:27C4CB52-A0FE-496F-B41D-86955F2012DB@.microsoft.com...
> Hello Mike,
> Thank you!
> Your reply cleared things up.
> I was aware of the "Acquire Late, Release Early" principle - but felt very
> very uncomfortable when I saw a bunch of DB level locks hanging around for
> extended periods of time.
> Cheers!
> SQLCatZ
>

Current Activity : Locks/Object : DB Level locks.

The Current Activity monitor (Locks/Object) shows a number of processes that
have obtained a database level lock.
Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
What causes these db level locks?
All are SHARED level locks - and the status for is GRANT - meaning that the
lock has been successfully obtained.
How can I prevent these locks from appearing?
Cheers!
SQLCatZ
Hi
Every connection will acquire a DB level lock when the connection is
established, to the database specified in the connection string from the
client..
This enables SQL Server to do a very fast lookup to see if a DB is in use
(for auto close, detach, drop database etc).
It is a shared lock.
You can not set this.
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:DA43536F-E52A-4D1A-AB83-6433FEA6D1BD@.microsoft.com...
> The Current Activity monitor (Locks/Object) shows a number of processes
> that
> have obtained a database level lock.
> Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
> What causes these db level locks?
> All are SHARED level locks - and the status for is GRANT - meaning that
> the
> lock has been successfully obtained.
> How can I prevent these locks from appearing?
> Cheers!
> SQLCatZ
>
>
|||Hello Mike,
If the connection is established only to check on the status of the db -
then it should be a for a very short duration. The entry for this kind of
lock should appear and then disappear from the 'Current Activity :
Locks/Object' view. It should not persist for hours on end.
What should I look out for in the design/code that is creating these
multiple db level locks to persist for extended periods of time.
Thank you.
SQLCatZ
|||Hi
The client connection, as long as it is open, holds the DB Shared Lock (SQL
Server does it on it's behalf).
There is nothing wrong with those locks, and at most, there could be 32'737
of them if all connections are used that SQL Server supports.
It is a small number compared to the locks required my most SELECT and
UPDATE operations.
The application should also be looked at. The principle of "Acquire Late,
Release Early" should always be applied. An application should not open a
connection and hold it open until it gets closed, rather, it should open the
connection, do it's query, and close the connection again. Connection
pooling will negate any performance problems related to establishing and
tearing down connections in short intervals.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:98FF664C-472A-4A50-B383-719E37F10BFE@.microsoft.com...
> Hello Mike,
> If the connection is established only to check on the status of the db -
> then it should be a for a very short duration. The entry for this kind of
> lock should appear and then disappear from the 'Current Activity :
> Locks/Object' view. It should not persist for hours on end.
> What should I look out for in the design/code that is creating these
> multiple db level locks to persist for extended periods of time.
> Thank you.
> SQLCatZ
>
>
|||Hello Mike,
Thank you!
Your reply cleared things up.
I was aware of the "Acquire Late, Release Early" principle - but felt very
very uncomfortable when I saw a bunch of DB level locks hanging around for
extended periods of time.
Cheers!
SQLCatZ
|||Basically Db locks prevent anyone from doing RESTORE and DROP DATABASE. When MS looked into how
prohibiting these actions for 7.0, they realized that using the already present lock handing would
be a clean way of doing it.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:27C4CB52-A0FE-496F-B41D-86955F2012DB@.microsoft.com...
> Hello Mike,
> Thank you!
> Your reply cleared things up.
> I was aware of the "Acquire Late, Release Early" principle - but felt very
> very uncomfortable when I saw a bunch of DB level locks hanging around for
> extended periods of time.
> Cheers!
> SQLCatZ
>

Current Activity : Locks/Object : DB Level locks.

The Current Activity monitor (Locks/Object) shows a number of processes that
have obtained a database level lock.
Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
What causes these db level locks?
All are SHARED level locks - and the status for is GRANT - meaning that the
lock has been successfully obtained.
How can I prevent these locks from appearing?
Cheers!
SQLCatZHi
Every connection will acquire a DB level lock when the connection is
established, to the database specified in the connection string from the
client..
This enables SQL Server to do a very fast lookup to see if a DB is in use
(for auto close, detach, drop database etc).
It is a shared lock.
You can not set this.
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:DA43536F-E52A-4D1A-AB83-6433FEA6D1BD@.microsoft.com...
> The Current Activity monitor (Locks/Object) shows a number of processes
> that
> have obtained a database level lock.
> Details: (Mode:Shared, Status:GRANT, Owner:SESSION)
> What causes these db level locks?
> All are SHARED level locks - and the status for is GRANT - meaning that
> the
> lock has been successfully obtained.
> How can I prevent these locks from appearing?
> Cheers!
> SQLCatZ
>
>|||Hello Mike,
If the connection is established only to check on the status of the db -
then it should be a for a very short duration. The entry for this kind of
lock should appear and then disappear from the 'Current Activity :
Locks/Object' view. It should not persist for hours on end.
What should I look out for in the design/code that is creating these
multiple db level locks to persist for extended periods of time.
Thank you.
SQLCatZ|||Hi
The client connection, as long as it is open, holds the DB Shared Lock (SQL
Server does it on it's behalf).
There is nothing wrong with those locks, and at most, there could be 32'737
of them if all connections are used that SQL Server supports.
It is a small number compared to the locks required my most SELECT and
UPDATE operations.
The application should also be looked at. The principle of "Acquire Late,
Release Early" should always be applied. An application should not open a
connection and hold it open until it gets closed, rather, it should open the
connection, do it's query, and close the connection again. Connection
pooling will negate any performance problems related to establishing and
tearing down connections in short intervals.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:98FF664C-472A-4A50-B383-719E37F10BFE@.microsoft.com...
> Hello Mike,
> If the connection is established only to check on the status of the db -
> then it should be a for a very short duration. The entry for this kind of
> lock should appear and then disappear from the 'Current Activity :
> Locks/Object' view. It should not persist for hours on end.
> What should I look out for in the design/code that is creating these
> multiple db level locks to persist for extended periods of time.
> Thank you.
> SQLCatZ
>
>|||Hello Mike,
Thank you!
Your reply cleared things up.
I was aware of the "Acquire Late, Release Early" principle - but felt very
very uncomfortable when I saw a bunch of DB level locks hanging around for
extended periods of time.
Cheers!
SQLCatZ|||Basically Db locks prevent anyone from doing RESTORE and DROP DATABASE. When MS looked into how
prohibiting these actions for 7.0, they realized that using the already present lock handing would
be a clean way of doing it.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"SQLCatz" <SQLCatz@.discussions.microsoft.com> wrote in message
news:27C4CB52-A0FE-496F-B41D-86955F2012DB@.microsoft.com...
> Hello Mike,
> Thank you!
> Your reply cleared things up.
> I was aware of the "Acquire Late, Release Early" principle - but felt very
> very uncomfortable when I saw a bunch of DB level locks hanging around for
> extended periods of time.
> Cheers!
> SQLCatZ
>

Currency Fromatting

Hi Everyone,
I am a bit of a newbie to SQL, I have created a table to hold supplier
invoice details which has three columns to hold currency values i.e.
Nett Value
VAT Value
Gross Value
The columns for VAT and gross calculate automatically from the Nett value,
however the values in the fields have more than 2 digits after the decimal
place i.e.
Nett Value = 275.00
VAT Value = 48.125
Gross Value = 323.125
How do I force the two calculating fields to format the contents to standard
currency format i.e. ￡xxx.xx with only 2 digits after the decimal point?
Hope that makes sense. Any help would be greatly appreciatedNote that in the UK (AFAIK same as the rest of the EU), accounting
regulations require that VAT be calculated on an invoice sub-total, not
on individual items (there may be a difference due to rounding) so what
you are doing will not represent the correct total for accounting
purposes.
Storing both Net and Gross columns in a table is poor design. This is
redundant data and most systems will store just the Net value at detail
level, plus a VAT code.
Formatting is probably best left to your client app or middle tier. If
you must do it in SQL then look up the style parameter of the CONVERT
function. Avoid using MONEY / SMALLMONEY columns in your tables though
as these have some problems with precision in division operations.
David Portas
SQL Server MVP
--|||Thanks for your reply David. I am aware that for official accounting it
would need to be line by line calculated, but my DB if purely for reporting
supplier turnover and not for accounting so I am not overly bothered about
the roundings, but thanks for the pointers I'll go and have aplay and see
what I get.
Cheers
Jonathan
"David Portas" wrote:

> Note that in the UK (AFAIK same as the rest of the EU), accounting
> regulations require that VAT be calculated on an invoice sub-total, not
> on individual items (there may be a difference due to rounding) so what
> you are doing will not represent the correct total for accounting
> purposes.
> Storing both Net and Gross columns in a table is poor design. This is
> redundant data and most systems will store just the Net value at detail
> level, plus a VAT code.
> Formatting is probably best left to your client app or middle tier. If
> you must do it in SQL then look up the style parameter of the CONVERT
> function. Avoid using MONEY / SMALLMONEY columns in your tables though
> as these have some problems with precision in division operations.
> --
> David Portas
> SQL Server MVP
> --
>

Cube design question

I have a Fact table which stores details about each revision made on the document.

There is a one to many relationship between a document and the revisions

I need to display information based on the last revision made by a particular UserType.

How do I select records from the fact table based on a particular UserType and the maximum revision number for that usertype?

Hi Reena,

Are you using AS 2000 or AS 2005?

So you have RevisionFact table and also Dim_Dt, Dim_UserType, Dim_Users, Dim_Doc etc. and you store every revisions in fact table along with UserTypeID, Date_ID, Doc_ID, and User_ID.

It would be easy if you tell what measures you store in fact table. You can use "Count" Aggregate Function in measure and query using UserType , Date and measure count on the field you store for each revisions in fact table.

-Ashok

|||

I am using AS 2005

I need to display the count of documents that were written within the target time as well as the count of documents that were not written within the target time set for each user.

The user list has to be displayed along the rows and the count of documents along the columns ( 2 columns)

I have measures that would display time taken to write a document and target time for the document.

Using COUNT function I can get the count of documents written by a user.

But how do I break that count up into two separate columns displaying number of documents written within target time and number of documents written outside target time - for each user?

|||

There are a few ways you could do this, but here's one suggestion. Its a very simple pattern which csn be used again and again for similar problems.

You have a table or view with the time taken and target time in as columns.

Add another column (this is easier if you have a view) and define it as:

case when TimeTaken>TargetTime then 0 else 1 end as TargetMetId

create a lookup table as TargetMet with values

0,"Target Not Met"

1,"Target Met"

You can then link the 2 together and create a nice TargetMet Dimension. This will give you all of the counts you require.

You can expand this by changing the case statment, and building a lookup table like this

1,"Finished Same Day"

2,"Finished Early"

3,"On Time"

4,"A bit late"

5,"Do they still work here?"

etc

|||Thanks for the reply.