Procedure Time out: total

Showing posts with label total. Show all posts

Monday, March 26, 2012

Product qty in a given branch

Hi,
I'm new to queries and I'm stuck with joins...
I have the following tables, and would like to get the total of the
products, given a BranchId:
table Product
ProductId: PK
ProductName
table Branch
BranchId
table Inventory
InventoryId: PK
BranchId: FK to Branch.BranchId
table InventoryDetail
InventoryDetailId: PK
InventoryId: FK to Inventory.InventoryId
ProductId: FK to Product.ProductId
Quantity
Here is what I started:
CREATE PROCEDURE SelectProductByName(@.BranchId INT, @.ProductName
NVARCHAR(100))
AS
SELECT P.ProductId, P.ProductName, Sum(ID.Quantity) AS Qty
FROM Product AS P
LEFT JOIN InventoryDetail AS ID ON ID.ProductId = P.ProductId
/*And waht now with*/
RETURNHello, Michael
I guess you want something like this:
SELECT P.ProductId, P.ProductName, X.Qty
FROM Product AS P LEFT JOIN (
SELECT ID.ProductId, Sum(ID.Quantity) AS Qty
FROM InventoryDetail ID
INNER JOIN Inventory I ON ID.InventoryId = I.InventoryId
WHERE I.BranchId = @.BranchId
GROUP BY ID.ProductId
) X ON P.Product = X.ProductId
WHERE P.ProductName = @.ProductName
This query may also work, but the first query is better:
SELECT P.ProductId, P.ProductName, Sum(ID.Quantity) AS Qty
FROM Product AS P
LEFT JOIN InventoryDetail ID ON P.ProductId = ID.ProductId
LEFT JOIN Inventory I ON ID.InventoryId = I.InventoryId
AND I.BranchId = @.BranchId
WHERE P.ProductName = @.ProductName
GROUP BY P.ProductId, P.ProductName
Razvan|||Hi Razvan,
Thank you very much for the help.
Why is the first first query better than the second one?
Also, I've come up with the following query. Is it correct?
SELECT P.ProductId, P.ProductName,
(SELECT SUM(ID.Quantity) FROM InventoryDetail AS ID
JOIN Inventory AS I ON I.InventoryId = ID.InventoryId
WHERE (I.BranchId = @.BranchId) AND (ID.ProductId = P.ProductId))
AS Qty
FROM Product AS P
WHERE (P.ProductName = @.ProductName)
Regards
Razvan Socol wrote:
> Hello, Michael
> I guess you want something like this:
> SELECT P.ProductId, P.ProductName, X.Qty
> FROM Product AS P LEFT JOIN (
> SELECT ID.ProductId, Sum(ID.Quantity) AS Qty
> FROM InventoryDetail ID
> INNER JOIN Inventory I ON ID.InventoryId = I.InventoryId
> WHERE I.BranchId = @.BranchId
> GROUP BY ID.ProductId
> ) X ON P.Product = X.ProductId
> WHERE P.ProductName = @.ProductName
> This query may also work, but the first query is better:
> SELECT P.ProductId, P.ProductName, Sum(ID.Quantity) AS Qty
> FROM Product AS P
> LEFT JOIN InventoryDetail ID ON P.ProductId = ID.ProductId
> LEFT JOIN Inventory I ON ID.InventoryId = I.InventoryId
> AND I.BranchId = @.BranchId
> WHERE P.ProductName = @.ProductName
> GROUP BY P.ProductId, P.ProductName
> Razvan
>|||Hello, Michael

> Why is the first first query better than the second one?
Before testing the queries (because I had no DDL and sample data, see:
http://www.aspfaq.com/etiquette.asp?id=5006), I wrote that the first
query is better, because the second query seemed unsafe to me. Now that
I've tested it (by translating it for one of my own schemas), I can say
that the second query is plain wrong: it doesn't return the expected
results. I intended to write the second query this way:
SELECT P.ProductId, P.ProductName, Sum(ID.Quantity) AS Qty
FROM Product AS P
LEFT JOIN InventoryDetail ID
INNER JOIN Inventory I ON ID.InventoryId = I.InventoryId
ON P.ProductId = ID.ProductId AND I.BranchId = @.BranchId
WHERE P.ProductName = @.ProductName
GROUP BY P.ProductId, P.ProductName
Regarding the weird placement of the ON clause, see:
http://groups.google.com/group/micr...br />
2579509b

> Also, I've come up with the following query. Is it correct?
Yes, it is correct. Actually, I think it's identical (in terms of
performance) with my first query, but your query is better because is
more readable. The corrected second query (although it produces an
execution plan with the same cost as the other two), seems to me a bit
slower, because the "Stream Aggregate" step (the GROUP BY clause) is
done on a wider row. Also, it's a lot harder to understand, so that's
why I still think it's the worse among the three queries.
Razvan|||Hi Razvan,
Sorry, I didn't provide the DDL. Now that I know how to do it, I'll
provide it next time.
I'll go on with my query as I already understood it, keeping a copy of
yours if needed.
Thanks a lot
Razvan Socol wrote:
> Hello, Michael
>
>
> Before testing the queries (because I had no DDL and sample data, see:
> http://www.aspfaq.com/etiquette.asp?id=5006), I wrote that the first
> query is better, because the second query seemed unsafe to me. Now that
> I've tested it (by translating it for one of my own schemas), I can say
> that the second query is plain wrong: it doesn't return the expected
> results. I intended to write the second query this way:
> SELECT P.ProductId, P.ProductName, Sum(ID.Quantity) AS Qty
> FROM Product AS P
> LEFT JOIN InventoryDetail ID
> INNER JOIN Inventory I ON ID.InventoryId = I.InventoryId
> ON P.ProductId = ID.ProductId AND I.BranchId = @.BranchId
> WHERE P.ProductName = @.ProductName
> GROUP BY P.ProductId, P.ProductName
> Regarding the weird placement of the ON clause, see:
> http://groups.google.com/group/micr... />
492579509b
>
>
> Yes, it is correct. Actually, I think it's identical (in terms of
> performance) with my first query, but your query is better because is
> more readable. The corrected second query (although it produces an
> execution plan with the same cost as the other two), seems to me a bit
> slower, because the "Stream Aggregate" step (the GROUP BY clause) is
> done on a wider row. Also, it's a lot harder to understand, so that's
> why I still think it's the worse among the three queries.
> Razvan
>|||Please post DDL, so that people do not have to guess what the keys,
constraints, Declarative Referential Integrity, data types, etc. in
your schema are. Sample data is also a good idea, along with clear
specifications. It is very hard to debug code when you do not let us
see it.
Since you also did not give any specs, can I assume that inventory is
spread over branches? Can I assume the product is identified by some
industry standard code, such as a UPC? And why did you create that
useless inventory details table? An inventory is not like an invoice.
CREATE TABLE Products
(upc CHAR(13) NOT NULL PRIMARY KEY, --upc?
product_name CHAR(20) NOT NULL,
.);
CREATE TABLE Branches
(branch_id INTEGER NOT NULL PRIMARY KEY,
.);
CREATE TABLE Inventory
(branch_id INTEGER NOT NULL
REFERENCES Branches(branch_id),
upc CHAR(13) NOT NULL
REFERENCES Products(upc),
PRIMARY KEY (branch_id, upc),
qty_on_hand INTEGER DEFAULT 0 NOT NULL
CHECK (qty_on_hand >= 0)
The right design makes it easy:
SELECT P.upc, SUM(I.qty_on_hand)
FROM Products AS P
LEFT OUTER JOIN
Inventory AS I
ON P.upc= I.upc
GROUP BY P.upc;|||Hi Celko,
I already got an answer from Razvan.
I needed the inventory detail table to hold the different quantities
with their respective notes, such as bin location, qty of damaged items
included in the inventory,...
Now that I know how to post DDL, I'll do it next time. As for the sample
data, I don't have any yet. I'm starting to design the database from
scratch.
Thanks for the help
--CELKO-- wrote:
> Please post DDL, so that people do not have to guess what the keys,
> constraints, Declarative Referential Integrity, data types, etc. in
> your schema are. Sample data is also a good idea, along with clear
> specifications. It is very hard to debug code when you do not let us
> see it.
> Since you also did not give any specs, can I assume that inventory is
> spread over branches? Can I assume the product is identified by some
> industry standard code, such as a UPC? And why did you create that
> useless inventory details table? An inventory is not like an invoice.
> CREATE TABLE Products
> (upc CHAR(13) NOT NULL PRIMARY KEY, --upc?
> product_name CHAR(20) NOT NULL,
> ..);
> CREATE TABLE Branches
> (branch_id INTEGER NOT NULL PRIMARY KEY,
> ..);
> CREATE TABLE Inventory
> (branch_id INTEGER NOT NULL
> REFERENCES Branches(branch_id),
> upc CHAR(13) NOT NULL
> REFERENCES Products(upc),
> PRIMARY KEY (branch_id, upc),
> qty_on_hand INTEGER DEFAULT 0 NOT NULL
> CHECK (qty_on_hand >= 0)
>
>
> The right design makes it easy:
> SELECT P.upc, SUM(I.qty_on_hand)
> FROM Products AS P
> LEFT OUTER JOIN
> Inventory AS I
> ON P.upc= I.upc
> GROUP BY P.upc;
>|||>> I needed the inventory detail table to hold the different quantities with
their respective notes, such as bin location, qty of damaged items included
in the inventory,...<<
That is the usual inventory design; several different quantity
attributes (on-hand, on order, on hold, damaged, expired, etc. Since
these are all distinct attributes of an inventory held at a p[articular
branch, you simply extend the table. That data and the needed check
constraints were not shown in your specs (or lack of specs, really).
There is no need to create a separate inventory_id., which is a poor
attempt at a surrogate for a branch_id. You are splitting the actual
primary key (branch_id, upc) across tables. Ask yourself what meaning
an inventory has apart from the goods it holds. Look at your
pseudo-code; what maps yhour magical "InventoryDetailId" to one and
only one product, and assures that it is the RIGHT product? Nothing.
The split key invites disaster.
Please consider a correct design instead.|||Designing a database is not so simple...
I've already changed my design several times. At first because of a lack
of knowledge in database design (this is actually my first database with
SqlServer, before this was 2 simple databases with MS Access)
If you don't mind I'll really need a help. I'll try to make it as simple
as I can.
Our company has 2 branches (I'll generalise this to several branches).
Products can be stocked in either of these branches.
When counting a product, we need the date of the counting, and the
details (quantity + comments, such as damaged, carton no, bin
location,... which are "free-hand" text note). Note that branches count
their products independently of each other.
So, I came up with these tables:
CREATE TABLE Product (
ProductId BIGINT IDENTITY PRIMARY KEY,
ProductName NVARCHAR(50) NOT NULL,
..
)
CREATE TABLE Branch (
BranchId INT IDENTITY PRIMARY KEY,
BranchName NVARCHAR(50) NOT NULL,
..
)
CREATE TABLE Inventory (
InventoryId BIGINT IDENTITY PRIMARY KEY,
InventoryDate DATETIME NOT NULL,
BranchId INT NOT NULL REFERENCES Branch(BranchId),
..
)
CREATE TABLE InventoryDetail (
InventoryDetailId BIGINT IDENTITY PRIMARY KEY,
InventoryId BIG INT NOT NULL REFERENCES Inventory(InventoryId),
ProductId BIG INT NOT NULL REFERENCES Product(ProductId),
Quantity INT NOT NULL,
Comments NVARCHAR(100) NULL
)
As for sample data, I don't have any yet, but here is what we want:
Lady coat no 634:
Main branch: counted on 14/02/06
- 60 pcs, ctn 123
- 6 pcs, on the shelf (in the shop)
Second branch: counted on 16/02/06
- 3 pcs, on the shelf
Lady pant no 132:
Main branch: counted on 21/02/06
- 2 pcs, a customer has specially ordered these for himself
Lady shoes no 852:
Main branch: counted on 22/02/06
- 12 pcs, in stock shelf no 3
- 12 pcs, waiting to be sent to branch 2
- 2 pcs, in the shop
Second branch: counted on 20/02/06
- 0 pcs, placed the order from Main branch already
--CELKO-- wrote:
>
> That is the usual inventory design; several different quantity
> attributes (on-hand, on order, on hold, damaged, expired, etc. Since
> these are all distinct attributes of an inventory held at a p[articular
> branch, you simply extend the table. That data and the needed check
> constraints were not shown in your specs (or lack of specs, really).
> There is no need to create a separate inventory_id., which is a poor
> attempt at a surrogate for a branch_id. You are splitting the actual
> primary key (branch_id, upc) across tables. Ask yourself what meaning
> an inventory has apart from the goods it holds. Look at your
> pseudo-code; what maps yhour magical "InventoryDetailId" to one and
> only one product, and assures that it is the RIGHT product? Nothing.
> The split key invites disaster.
> Please consider a correct design instead.
>

Friday, March 23, 2012

ProClarity Desktop Professional 6.3 - Totals Performance

I am using PDP 6.3. When I try to put a total on my grid, it basically kills ProClarity. I know there was a problem with Totals in older versions of PDP, but I thought it would have been fixed by now. Is there some workaround or hotfix?

Thanks,

Linda Fleming

Hello Linda! I have not seen performance issues with ProClarity totals but can you send some more information regarding your problem?

Can you recreate the problem on the Adventure Works sample cube or can you tell us more about the structure of your cube?

Regards

Thomas Ivarsson

|||

Thomas,

(Note: I tried using a partition but did not make any difference because I think the problem is with the large number of dimension rows and not the fact table)

factTable: 200,000 rows.

I want subtotals in my view by Stage, but the query never returns.

All Companies has 1614 rows

All Opportunities has 406 rows

Here is my MDX:

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

NON EMPTY { { { [Stage].[Stage].&[10 - Confirmed], [Stage].[Stage].&[20 - Qualified], [Stage].[Stage].&[30 - Proposed] } * { DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) } * { DESCENDANTS( [Opportunity].[Opportunity].[All Opportunities], , LEAVES ) } } } ON ROWS

FROM [Daily Pipeline Snapshot]

WHERE ( [Measures].[Opportunity Value], [Sales Rep].[Sales Rep].&[TAYLOR], [Opportunity Status].[Opportunity Status].[Op Status].&[Open], [Probability].[Probability Description].[All Probability] )

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

I can send you my cube if this would expedite things.

|||

Hello Linda. I think that the problem relates to that you crossjoin several dimensions, one of them at the leaf level.

I do not know how many members you have in each dimensions but if you can do subtotals on the Adventure Works cube it is probably the design of the cube that decides this.

If you remove some dimensions in the crossjoin and only start with the first two? Will it work?

HTH

Thomas Ivarsson

|||

Hi,

There isn't a work around or hotfix for the problem, we had the same problem and users have been banded from including them in their queries.

Most of the time you don't need to use ProClarity's Total options, if you are selecting every child of an attribute, you can just include the all level as well and that will give you a total e.g.

All Opps

-opp1

-opp2

-opp3

SELECT { [Measures].[Measure1] } ON COLUMNS ,
{ [Dim].[Opps].[All Opps], [Dim].[Opps].&[Opp1], [Dim].[Opps].&[Opp2],[Dim].[Opps].&[Opp3] } ON ROWS
FROM [fact]

would give you an all level (total)

Measure

All 20

opp1 5

opp2 5

opp3 10

If you're not using all the members in the attribute, I wouldn't let ProClarity build your MDX statement with totals. It ends up writing the most inefficient code ever, hence why proclarity dies. Perhaps write your own MDX and paste it in the MDX viewer.

HTH

Matt

|||

Good point Mark but if the subtotal feature is usable or useless depends on how many cells that you call with several dimensions on an axis and on the leaf level.

No tool can manage that!

Regards

Thomas Ivarsson

|||

I wasn't really saying it was, I was just impling that ProClarity generates rubbish code. I am sure some careful planning of a report or generating your own MDX is more efficent than using ProClarity's total functions.

I was perhaps offereing a work around for the problem seeing as there wasn't a fix.

Mark AKA Matt

|||

Hello Matt. I will try your solution.

The problem with your approach is that your own MDX will be changed to ProClarity MDX as soon as a user start to change your report. Your solution will probably work well with SSRS2005 or if you publish static ProClarity reports.

I have published several complaints about ProClarity's implementation of MDX on my blog.

Regards

Thomas Ivarsson

|||

Matt,

Thank you for your comments. Our company has been struggling with the Totals for several years and just keep hoping it gets fixed. I notice it uses the Aggregate function. Maybe SUM would be better? I will keep working on it, but Thomas has a good point that you can't start analyzing the view. If it is a static view on the dashboard I suppose custom MDX would work.

Linda

Thomas,

I took off the 3rd dimension (Opportunity) and the subtotals worked. Here is my MDX:

WITH MEMBER [Company].[Company].[All Companies].[ Subtotal]

AS ' AGGREGATE( EXISTING

{ DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) }) ',

SOLVE_ORDER = 1000

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

NON EMPTY { { { { [Stage].[Stage].&[10 - Confirmed], [Stage].[Stage].&[20 - Qualified], [Stage].[Stage].&[30 - Proposed] } } * { { [Company].[Company].[All Companies].[ Subtotal] }, { DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) } } } } ON ROWS

FROM [Daily Pipeline Snapshot]

WHERE ( [Measures].[Opportunity Value], [Sales Rep].[Sales Rep].[All Sales Rep], [Opportunity Status].[Opportunity Status].[Op Status].&[Open], [Probability].[Probability Description].[All Probability] )

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

However, now, I don't know what to try next since I really need that last dimension. Is there a possible solution? I would really like to send you my cube and let you experiment with it. Is that an option?

Linda

|||

Hi,

Still a little confused by what you are both saying, as I can produce something identical to what you are suggesting in ProClarity and still slice and dice it afterwards. So that wouldn't imply it was static.

e,g, You code looks something like:

Code Snippet

WITH MEMBER [Campaign].[Campaign Region].[All Campaigns].[ Subtotal]

' AGGREGATE( EXISTING { [Campaign].[Campaign Region].[All Campaigns].CHILDREN }) ',

SOLVE_ORDER = 1000

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns].CHILDREN },

{ [Campaign].[Campaign Region].[All Campaigns].[ Subtotal] } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

mine looks something like

Code Snippet

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns]},

{ [Campaign].[Campaign Region].[All Campaigns].children } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

They both produce the same results and I can slice it later on. I didn't write the code; I used ProClarity to generate it, so there is no reformatting. Which I know is an issue if you start having drop down slicers or usign subcubes. The performance hit is less as well with mine, on a cold cache the top one ran 13secs lower one 3 secs.

The only difference is I have an "All level" at the top and you have a "sub total" at the bottom.

The only down side to it as far as i can see it is if you don't include all the members of the dimension then the "All level" doesn't work.

And no matter what you code to fix the issue, as soon as you drill into something ProClarity will revert it back to using its way of MDX. So you could have a fancy quick query on the first page but as soon as you drill into a level, you still going to lose your code and perhaps incur a performance hit. Which I found out when I drilled into mine, ProClarity reverted it back to using subtotals.

You could always try caching the results (common ones) that way when your uses run their queries they hit the cache first. I believe chris webb has a blog on cache warming.

Matt

|||

Hello Linda! This one

Code Snippet

{ [Next 3 Months Anticipated Close] }

on columns is that a calculated member, calculated measure, named set or dimension member?

You can send me the cube but the problem is that we cannot change ProClarity's MDX behaviour. Have you tried the same view/query in Excel 2007? I think you can download a trial version only to see if there is a difference between these clients.

Regards

Thomas Ivarsson

|||

Thomas,

[Next 3 Months Anticipated Close] is a named set.

STRTOSET(

"[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0):
[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0).Lead(2)")

Where can I send the cube? I would like you to look at it and see if you get the same behavior I do.

Can Excel 2007 read cubes?

Linda

|||

Linda! Excel2007 supports all SSAS2005 features except writeback. Try that option first and see if it helps.

It can reveal if it is ProClarity's MDX that is the problem.

How large is the cube? If it is large you may have to place it on an FTP-site.

If you look at my profile you can see my email.

STRTOSET is not good for performance. Is that a dynamic,running month, set?

Regards

Thomas Ivarsson

Regards

Thomas Ivarsson

|||

Thomas,

We have Excel2007. I will install it and try it.

The data warehouse is 10,500 KB.

Yes, it is a dynamic running month set. What can I use instead of STRTOSET?

Thanks,

Linda

|||Linda! I have an example here: http://thomasianalytics.spaces.live.com/blog/cns!B6B6A40B93AE1393!352.entry

There are many other ways to solve this.

I think you can send the cube directly.

Regards

Thomas Ivarsson

ProClarity Desktop Professional 6.3 - Totals Performance

Thanks,

Linda Fleming

Hello Linda! I have not seen performance issues with ProClarity totals but can you send some more information regarding your problem?

Can you recreate the problem on the Adventure Works sample cube or can you tell us more about the structure of your cube?

Regards

Thomas Ivarsson

|||

Thomas,

(Note: I tried using a partition but did not make any difference because I think the problem is with the large number of dimension rows and not the fact table)

factTable: 200,000 rows.

I want subtotals in my view by Stage, but the query never returns.

All Companies has 1614 rows

All Opportunities has 406 rows

Here is my MDX:

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

WHERE ( [Measures].[Opportunity Value], [Sales Rep].[Sales Rep].&[TAYLOR], [Opportunity Status].[Opportunity Status].[Op Status].&[Open], [Probability].[Probability Description].[All Probability] )

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

I can send you my cube if this would expedite things.

|||

Hello Linda. I think that the problem relates to that you crossjoin several dimensions, one of them at the leaf level.

I do not know how many members you have in each dimensions but if you can do subtotals on the Adventure Works cube it is probably the design of the cube that decides this.

If you remove some dimensions in the crossjoin and only start with the first two? Will it work?

HTH

Thomas Ivarsson

|||

Hi,

There isn't a work around or hotfix for the problem, we had the same problem and users have been banded from including them in their queries.

Most of the time you don't need to use ProClarity's Total options, if you are selecting every child of an attribute, you can just include the all level as well and that will give you a total e.g.

All Opps

-opp1

-opp2

-opp3

SELECT { [Measures].[Measure1] } ON COLUMNS ,
{ [Dim].[Opps].[All Opps], [Dim].[Opps].&[Opp1], [Dim].[Opps].&[Opp2],[Dim].[Opps].&[Opp3] } ON ROWS
FROM [fact]

would give you an all level (total)

Measure

All 20

opp1 5

opp2 5

opp3 10

HTH

Matt

|||

Good point Mark but if the subtotal feature is usable or useless depends on how many cells that you call with several dimensions on an axis and on the leaf level.

No tool can manage that!

Regards

Thomas Ivarsson

|||

I was perhaps offereing a work around for the problem seeing as there wasn't a fix.

Mark AKA Matt

|||

Hello Matt. I will try your solution.

I have published several complaints about ProClarity's implementation of MDX on my blog.

Regards

Thomas Ivarsson

|||

Matt,

Linda

Thomas,

I took off the 3rd dimension (Opportunity) and the subtotals worked. Here is my MDX:

WITH MEMBER [Company].[Company].[All Companies].[ Subtotal]

AS ' AGGREGATE( EXISTING

{ DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) }) ',

SOLVE_ORDER = 1000

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

Linda

|||

Hi,

e,g, You code looks something like:

Code Snippet

WITH MEMBER [Campaign].[Campaign Region].[All Campaigns].[ Subtotal]

' AGGREGATE( EXISTING { [Campaign].[Campaign Region].[All Campaigns].CHILDREN }) ',

SOLVE_ORDER = 1000

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns].CHILDREN },

{ [Campaign].[Campaign Region].[All Campaigns].[ Subtotal] } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

mine looks something like

Code Snippet

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns]},

{ [Campaign].[Campaign Region].[All Campaigns].children } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

The only difference is I have an "All level" at the top and you have a "sub total" at the bottom.

The only down side to it as far as i can see it is if you don't include all the members of the dimension then the "All level" doesn't work.

You could always try caching the results (common ones) that way when your uses run their queries they hit the cache first. I believe chris webb has a blog on cache warming.

Matt

|||

Hello Linda! This one

Code Snippet

{ [Next 3 Months Anticipated Close] }

on columns is that a calculated member, calculated measure, named set or dimension member?

Regards

Thomas Ivarsson

|||

Thomas,

[Next 3 Months Anticipated Close] is a named set.

STRTOSET(

"[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0):
[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0).Lead(2)")

Where can I send the cube? I would like you to look at it and see if you get the same behavior I do.

Can Excel 2007 read cubes?

Linda

|||

Linda! Excel2007 supports all SSAS2005 features except writeback. Try that option first and see if it helps.

It can reveal if it is ProClarity's MDX that is the problem.

How large is the cube? If it is large you may have to place it on an FTP-site.

If you look at my profile you can see my email.

STRTOSET is not good for performance. Is that a dynamic,running month, set?

Regards

Thomas Ivarsson

Regards

Thomas Ivarsson

|||

Thomas,

We have Excel2007. I will install it and try it.

The data warehouse is 10,500 KB.

Yes, it is a dynamic running month set. What can I use instead of STRTOSET?

Thanks,

Linda

|||Linda! I have an example here: http://thomasianalytics.spaces.live.com/blog/cns!B6B6A40B93AE1393!352.entry

There are many other ways to solve this.

I think you can send the cube directly.

Regards

Thomas Ivarsson

ProClarity Desktop Professional 6.3 - Totals Performance

Thanks,

Linda Fleming

Hello Linda! I have not seen performance issues with ProClarity totals but can you send some more information regarding your problem?

Can you recreate the problem on the Adventure Works sample cube or can you tell us more about the structure of your cube?

Regards

Thomas Ivarsson

|||

Thomas,

(Note: I tried using a partition but did not make any difference because I think the problem is with the large number of dimension rows and not the fact table)

factTable: 200,000 rows.

I want subtotals in my view by Stage, but the query never returns.

All Companies has 1614 rows

All Opportunities has 406 rows

Here is my MDX:

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

WHERE ( [Measures].[Opportunity Value], [Sales Rep].[Sales Rep].&[TAYLOR], [Opportunity Status].[Opportunity Status].[Op Status].&[Open], [Probability].[Probability Description].[All Probability] )

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

I can send you my cube if this would expedite things.

|||

Hello Linda. I think that the problem relates to that you crossjoin several dimensions, one of them at the leaf level.

I do not know how many members you have in each dimensions but if you can do subtotals on the Adventure Works cube it is probably the design of the cube that decides this.

If you remove some dimensions in the crossjoin and only start with the first two? Will it work?

HTH

Thomas Ivarsson

|||

Hi,

There isn't a work around or hotfix for the problem, we had the same problem and users have been banded from including them in their queries.

Most of the time you don't need to use ProClarity's Total options, if you are selecting every child of an attribute, you can just include the all level as well and that will give you a total e.g.

All Opps

-opp1

-opp2

-opp3

SELECT { [Measures].[Measure1] } ON COLUMNS ,
{ [Dim].[Opps].[All Opps], [Dim].[Opps].&[Opp1], [Dim].[Opps].&[Opp2],[Dim].[Opps].&[Opp3] } ON ROWS
FROM [fact]

would give you an all level (total)

Measure

All 20

opp1 5

opp2 5

opp3 10

HTH

Matt

|||

Good point Mark but if the subtotal feature is usable or useless depends on how many cells that you call with several dimensions on an axis and on the leaf level.

No tool can manage that!

Regards

Thomas Ivarsson

|||

I was perhaps offereing a work around for the problem seeing as there wasn't a fix.

Mark AKA Matt

|||

Hello Matt. I will try your solution.

I have published several complaints about ProClarity's implementation of MDX on my blog.

Regards

Thomas Ivarsson

|||

Matt,

Linda

Thomas,

I took off the 3rd dimension (Opportunity) and the subtotals worked. Here is my MDX:

WITH MEMBER [Company].[Company].[All Companies].[ Subtotal]

AS ' AGGREGATE( EXISTING

{ DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) }) ',

SOLVE_ORDER = 1000

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

Linda

|||

Hi,

e,g, You code looks something like:

Code Snippet

WITH MEMBER [Campaign].[Campaign Region].[All Campaigns].[ Subtotal]

' AGGREGATE( EXISTING { [Campaign].[Campaign Region].[All Campaigns].CHILDREN }) ',

SOLVE_ORDER = 1000

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns].CHILDREN },

{ [Campaign].[Campaign Region].[All Campaigns].[ Subtotal] } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

mine looks something like

Code Snippet

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns]},

{ [Campaign].[Campaign Region].[All Campaigns].children } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

The only difference is I have an "All level" at the top and you have a "sub total" at the bottom.

The only down side to it as far as i can see it is if you don't include all the members of the dimension then the "All level" doesn't work.

You could always try caching the results (common ones) that way when your uses run their queries they hit the cache first. I believe chris webb has a blog on cache warming.

Matt

|||

Hello Linda! This one

Code Snippet

{ [Next 3 Months Anticipated Close] }

on columns is that a calculated member, calculated measure, named set or dimension member?

Regards

Thomas Ivarsson

|||

Thomas,

[Next 3 Months Anticipated Close] is a named set.

STRTOSET(

"[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0):
[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0).Lead(2)")

Where can I send the cube? I would like you to look at it and see if you get the same behavior I do.

Can Excel 2007 read cubes?

Linda

|||

Linda! Excel2007 supports all SSAS2005 features except writeback. Try that option first and see if it helps.

It can reveal if it is ProClarity's MDX that is the problem.

How large is the cube? If it is large you may have to place it on an FTP-site.

If you look at my profile you can see my email.

STRTOSET is not good for performance. Is that a dynamic,running month, set?

Regards

Thomas Ivarsson

Regards

Thomas Ivarsson

|||

Thomas,

We have Excel2007. I will install it and try it.

The data warehouse is 10,500 KB.

Yes, it is a dynamic running month set. What can I use instead of STRTOSET?

Thanks,

Linda

|||Linda! I have an example here: http://thomasianalytics.spaces.live.com/blog/cns!B6B6A40B93AE1393!352.entry

There are many other ways to solve this.

I think you can send the cube directly.

Regards

Thomas Ivarsson

ProClarity Desktop Professional 6.3 - Totals Performance

Thanks,

Linda Fleming

Hello Linda! I have not seen performance issues with ProClarity totals but can you send some more information regarding your problem?

Can you recreate the problem on the Adventure Works sample cube or can you tell us more about the structure of your cube?

Regards

Thomas Ivarsson

|||

Thomas,

(Note: I tried using a partition but did not make any difference because I think the problem is with the large number of dimension rows and not the fact table)

factTable: 200,000 rows.

I want subtotals in my view by Stage, but the query never returns.

All Companies has 1614 rows

All Opportunities has 406 rows

Here is my MDX:

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

WHERE ( [Measures].[Opportunity Value], [Sales Rep].[Sales Rep].&[TAYLOR], [Opportunity Status].[Opportunity Status].[Op Status].&[Open], [Probability].[Probability Description].[All Probability] )

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

I can send you my cube if this would expedite things.

|||

Hello Linda. I think that the problem relates to that you crossjoin several dimensions, one of them at the leaf level.

I do not know how many members you have in each dimensions but if you can do subtotals on the Adventure Works cube it is probably the design of the cube that decides this.

If you remove some dimensions in the crossjoin and only start with the first two? Will it work?

HTH

Thomas Ivarsson

|||

Hi,

There isn't a work around or hotfix for the problem, we had the same problem and users have been banded from including them in their queries.

Most of the time you don't need to use ProClarity's Total options, if you are selecting every child of an attribute, you can just include the all level as well and that will give you a total e.g.

All Opps

-opp1

-opp2

-opp3

SELECT { [Measures].[Measure1] } ON COLUMNS ,
{ [Dim].[Opps].[All Opps], [Dim].[Opps].&[Opp1], [Dim].[Opps].&[Opp2],[Dim].[Opps].&[Opp3] } ON ROWS
FROM [fact]

would give you an all level (total)

Measure

All 20

opp1 5

opp2 5

opp3 10

HTH

Matt

|||

Good point Mark but if the subtotal feature is usable or useless depends on how many cells that you call with several dimensions on an axis and on the leaf level.

No tool can manage that!

Regards

Thomas Ivarsson

|||

I was perhaps offereing a work around for the problem seeing as there wasn't a fix.

Mark AKA Matt

|||

Hello Matt. I will try your solution.

I have published several complaints about ProClarity's implementation of MDX on my blog.

Regards

Thomas Ivarsson

|||

Matt,

Linda

Thomas,

I took off the 3rd dimension (Opportunity) and the subtotals worked. Here is my MDX:

WITH MEMBER [Company].[Company].[All Companies].[ Subtotal]

AS ' AGGREGATE( EXISTING

{ DESCENDANTS( [Company].[Company].[All Companies], [Company].[Company].[Company] ) }) ',

SOLVE_ORDER = 1000

SELECT NON EMPTY { [Next 3 Months Anticipated Close] } ON COLUMNS ,

FROM [Daily Pipeline Snapshot]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

Linda

|||

Hi,

e,g, You code looks something like:

Code Snippet

WITH MEMBER [Campaign].[Campaign Region].[All Campaigns].[ Subtotal]

' AGGREGATE( EXISTING { [Campaign].[Campaign Region].[All Campaigns].CHILDREN }) ',

SOLVE_ORDER = 1000

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns].CHILDREN },

{ [Campaign].[Campaign Region].[All Campaigns].[ Subtotal] } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

mine looks something like

Code Snippet

SELECT { [Measures].[Charge Out] } ON COLUMNS ,

NON EMPTY { { [Campaign].[Regular Campaign Flag].&[0],

[Campaign].[Regular Campaign Flag].&[1.] } *

{ { [Campaign].[Campaign Region].[All Campaigns]},

{ [Campaign].[Campaign Region].[All Campaigns].children } } } ON ROWS

FROM [Self Service Prototype 3]

CELL PROPERTIES VALUE, FORMATTED_VALUE, CELL_ORDINAL

The only difference is I have an "All level" at the top and you have a "sub total" at the bottom.

The only down side to it as far as i can see it is if you don't include all the members of the dimension then the "All level" doesn't work.

You could always try caching the results (common ones) that way when your uses run their queries they hit the cache first. I believe chris webb has a blog on cache warming.

Matt

|||

Hello Linda! This one

Code Snippet

{ [Next 3 Months Anticipated Close] }

on columns is that a calculated member, calculated measure, named set or dimension member?

Regards

Thomas Ivarsson

|||

Thomas,

[Next 3 Months Anticipated Close] is a named set.

STRTOSET(

"[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0):
[Anticipated Close Date].[Hierarchy].[Month].&["

+ Format(Now(), "yyyy") + Format(Now(), "MM") + "].Item(0).Lead(2)")

Where can I send the cube? I would like you to look at it and see if you get the same behavior I do.

Can Excel 2007 read cubes?

Linda

|||

Linda! Excel2007 supports all SSAS2005 features except writeback. Try that option first and see if it helps.

It can reveal if it is ProClarity's MDX that is the problem.

How large is the cube? If it is large you may have to place it on an FTP-site.

If you look at my profile you can see my email.

STRTOSET is not good for performance. Is that a dynamic,running month, set?

Regards

Thomas Ivarsson

Regards

Thomas Ivarsson

|||

Thomas,

We have Excel2007. I will install it and try it.

The data warehouse is 10,500 KB.

Yes, it is a dynamic running month set. What can I use instead of STRTOSET?

Thanks,

Linda

|||Linda! I have an example here: http://thomasianalytics.spaces.live.com/blog/cns!B6B6A40B93AE1393!352.entry

There are many other ways to solve this.

I think you can send the cube directly.

Regards

Thomas Ivarssonsql

Friday, March 9, 2012

Processes blocking RESOURCE MONITOR, normal behaviour?

Today I ended up in a situation where I had a process with total six "subthreads" (identified by different execution context) (seen in Activity Monitor). All of these had blocking=1. The server didn't function properly, I don't know the details of these problems, since I was not present at that time. We had to kill the processes. What is the process id 1, "RESOURCE MONITOR" in SQL Server 2005, seen in Activity Monitor? Is it fatal if some processes are blocking RESOURCE MONITOR? How can one end up in such situation, is it normal or a bug somewhere?

The server is a 64-bit Windows server having SQL Server 2005 SP1.

Yesterday I had a CLR stored procedure running on another server. The procedure uses System.Data.SqlClient.SqlConnection to access this server. The procedure started about 11.4.2007 22:22. The procedure created a connection to the SQL Server and created a select that should return 1,5 million rows. During fetching the rows (about after 800 000 rows) the procedure crashes to an error:"".NET Framework execution was aborted by escalation policy because of out of memory. " Naturally the procedure couldn't close the SQL Server connections, since it was forced to end.

The details if the processes as seen from Actívity Monitor (I only have screenshots so I can't copy-paste...):

The main process:

Process id: 69

status: suspended

open transactions: 1

command: SELECT

Application: .NET SqlClient Data Provider

Wait time: 578

Wait type: ASYNC_NETWORK_ID

CPU: 1375

Physical IO: 22

Memory usage: 2

Last batch: 11.4.2007 22:22:05

Blocked by: 0

Blocking: 1

Execution context: 0

Two "subthreads", there are five similar.

Process id: 69

status: suspended

open transactions: 0

command: SELECT

Application: .NET SqlClient Data Provider

Wait time: 35293046

Wait type: CXPACKET

CPU: 4875

Physical IO: 2214

Memory usage: 2

Last batch: 11.4.2007 22:22:05

Blocked by: 0

Blocking: 1

Execution context: 1

Process id: 69

status: suspended

open transactions: 0

command: SELECT

Application: .NET SqlClient Data Provider

Wait time: 35293031

Wait type: CXPACKET

CPU: 4875

Physical IO: 2210

Memory usage: 2

Last batch: 11.4.2007 22:22:05

Blocked by: 0

Blocking: 1

Execution context: 2

The rest three subthreads differ from the above by having different wait time, CPU, physical IO and execution context.

Alright Chap,

You need to look at the "BLOCKED BY" rather than "BLOCKING" column.

The BLOCKING=1 means that this process is blocking another process.

Looking at the info you provided, the SPID 69 is not being blocked by any process.

Hope that helps.

Jag

|||

First off are you aware of the issue http://support.microsoft.com/kb/928083. I ask because one of its symptoms is the .NET framework message you mention and I just wanted to make certain you could eliminate it as a cause of that problem.

On the wait/blocking issue you may want to check out http://msdn2.microsoft.com/en-us/library/ms179984.aspx which describes the various wait states and a dynamic management view to look at them. The wait type that you are seeing (CXPACKET) is particularly associated with parallellisation of queries. There is a recommendation of trying reducing the degree of parallelism if you see a problem with this type of contention.

|||

Jag Sandhu wrote:

Alright Chap,

You need to look at the "BLOCKED BY" rather than "BLOCKING" column.

The BLOCKING=1 means that this process is blocking another process.

Looking at the info you provided, the SPID 69 is not being blocked by any process.

You are right, 69 is not blocking anything. I'm not interested in what 69 is blocking.

The problem is that 69 IS blocking SPID 1. SPID 1 is a system process, whose significance I don't know. During the problem 69 had been blocking 1 for a long time and the SQL server had been quite jammed. I was suspecting that the jamming was because the system process 1 couldn't do anythin being blocked by 69.

|||

Dhericean wrote:

First off are you aware of the issue http://support.microsoft.com/kb/928083. I ask because one of its symptoms is the .NET framework message you mention and I just wanted to make certain you could eliminate it as a cause of that problem.

Thanks for the information, I actually was unaware of the issue. This time I am not using a context connection, so the KB-entry is not valid in my case? I have two SQL Server instances and the CLR stored procedures run on instance A and use a "normal" SQL Server connection (instead of context connection) to connect to the server B.

Dhericean wrote:

On the wait/blocking issue you may want to check out http://msdn2.microsoft.com/en-us/library/ms179984.aspx which describes the various wait states and a dynamic management view to look at them. The wait type that you are seeing (CXPACKET) is particularly associated with parallellisation of queries. There is a recommendation of trying reducing the degree of parallelism if you see a problem with this type of contention.

OK, thanks for this information too. I find this CXPACKET issue also very strange since our database is in practise idle most of the time. And when this issue I reported happened the connection 69 had been in CXPACKET state for a while (don't know details, but maybe at least minutes). Shuoldn't the CXPACKET state change to something else after a while? Can this have something to do with the RESOURCE MONITOR process being blocked by process 69?

|||

Hi JM_F,

When BLOCKING column is set to 1 which means IT IS blocking another process. Other possible value for BLOCKING column is 0 which means it is not blocking any processes.

The values are 1 or 0 for Yes or NO respectively.

You have to use SP_who2 or DMV - sys.dm_exec_requests

and look for spid 69 in the BLOCKED by column.

regards

Jag

|||

Jag Sandhu wrote:

When BLOCKING column is set to 1 which means IT IS blocking another process. Other possible value for BLOCKING column is 0 which means it is not blocking any processes.

The values are 1 or 0 for Yes or NO respectively.

Hello Jag,

If I open Activity Monitor and click help, the following comes:

Blocked By
Process ID (SPID) of a blocking process.

Blocking
Process ID (SPID) of processes that are blocked.

This very clearly states that the value of blocking column contains the process ID. You say it contains 0 or 1. Are you sure of this?

|||

Hi JM,

To confirm, please see the books online topic - Activity Monitor (Process Info Page).

Process ID

SQL Server Process ID.

User

ID of the user who executed the command.

Database

Database currently being used by the process.

Status

Status of the process (for example, running, sleeping, runnable, and background).

Open Transactions

Number of open transactions for the process.

Command

Command currently being executed.

Application

Name of the application program being used by the process.

Wait Time

Current wait time in milliseconds. When the process is not waiting, the wait time is zero.

Wait Type

Indicates the name of the last or current wait type.

Resource

Textual representation of a lock resource.

CPU

Cumulative CPU time for the process. The entry is updated only for processes performed on behalf of Transact-SQL statements executed when SET STATISTICS TIME ON has been activated in the same session. The CPU column is updated when a query has been executed with SET STATISTICS TIME ON. When zero is returned, SET STATISTICS TIME is OFF.

Physical IO

Cumulative disk reads and writes for the process.

Memory Usage

Number of pages in the procedure cache that are currently allocated to this process. A negative number indicates that the process is freeing memory allocated by another process.

Login Time

Time at which a client process logged into the server. For system processes, the time at which SQL Server startup occurred is displayed.

Last Batch

Last time a client process executed a remote stored procedure call or an EXECUTE statement. For system processes, the displayed time is that at which SQL Server startup occurred.

Host

Name of the workstation.

Net Library

Column in which the client's network library is stored. Every client process comes in on a network connection. Network connections have a network library associated with them that allows them to make the connection. .

Net Address

Assigned unique identifier for the network interface card on each user's workstation. When the user logs in, this identifier is inserted in the Network Address column.

Blocked By

Process ID (SPID) of a blocking process.

Blocking

Indicates whether this process is blocking others. 1 = yes; 0 = no.

Execution Context

Execution context ID used to uniquely identify the subthreads operating on behalf of a single process.

|||

Jag Sandhu wrote:

To confirm, please see the books online topic - Activity Monitor (Process Info Page).

Blocking
Indicates whether this process is blocking others. 1 = yes; 0 = no.

Interesting... I found the entry you pointed in MSDN (http://msdn2.microsoft.com/en-us/library/ms178520.aspx). However the help page in my local installation (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/uirfsql9/html/12f87b09-bf20-4a69-8333-e67419472337.htm) contains the description I sent before. So these descriptions don't match.

Can I assume this a bug in SQL Server local documentation?

I have SQL Server 2005 SP 1 on Windows XP.

regards,

|||MS does a very good job of keeping sql bol on msdn2 current. You should download the latest one from http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx|||

Hi JM,

Please get the latest bol.

By the way, BLOCKING thing is even same for SQL 2000. So its always been like that.

regards

Jag

Monday, March 26, 2012

Product qty in a given branch

Friday, March 23, 2012

ProClarity Desktop Professional 6.3 - Totals Performance

ProClarity Desktop Professional 6.3 - Totals Performance

ProClarity Desktop Professional 6.3 - Totals Performance

ProClarity Desktop Professional 6.3 - Totals Performance

Friday, March 9, 2012

Processes blocking RESOURCE MONITOR, normal behaviour?

Procedure Time out

Blog Archive

About Me