DSO Questions

I am using DSO to list all the partitions (> 200) in my cube and then do a
threaded process of these partitions.
Thres questions:
1) I am using a grid to show all the partitions, whether they have been
processed or not and what their Estimated rows are. During population of
this grid (basically just iterating Cube.MDStores[x]), 9 times out of 10
I
get this random divide by zero error. I'm definately not causing this.
This is my loop:
for i:=1 to FCube.MDStores.Count do
begin
FPartition:=FCube.MDStores.Item(i);
FEstimatedRows:=FPartition.EstimatedRows;
sgPartitionList.Cells[0,i]:=FPartition.Name;
if FPartition.State = olapStateCurrent then
sgPartitionList.Cells[1,i]:='Processed'
else
sgPartitionList.Cells[1,i]:='No';
sgPartitionList.Cells[2,i]:=IntToStr(FEstimatedRows);
// Brain fart mentioned below goes here.
end;
Interestingly enough (2AM brain fart), I added this:
if i mod 12 = 0 then
begin
Application.ProcessMessages;
Sleep(500);
Application.ProcessMessages;
end;
to the loop (every 12 iterations, sleep 500 ms after processing all system
messages in the queue) and it works. Any idea why?
2) This same behavior presents itself during partition creation. At 225
partitions (without the message processing and pause), the OLE system kicks
back divide by zero errors or Access Violations. I've added the pause and
ProcessMessages to the creation loop and it's fine, but it worries me. Is
DSO really that flaky or am I missing something?
3) During partition process: I have a multi-threaded approach. I call
CoInitialize (to create a new OLE session because apparently DSO is not
threaded correctly) create a connection to the server, the database, the
cube and the partitions and then call FPartitionObject.Process;
This actually works great, but my question is, sporadically, the processing
just stops. I check the data directory and there won't have been any
updates to the files in several hours (as opposed to minutes when the
processing is working) and the CPU usage will be almost nil. I kill the
application, I also have to restart the OLAP service. There is no pattern
here, sometimes it'll process the whole cube (> 200 partitions), sometimes
it'll die at 50, sometimes 100, sometimes 4. Any Ideas? I've included my
Delphi source for the meat of the thread below.
procedure TPartitionProcessThread.Execute;
var
FServerObject, FDatabaseObject, FCubeObject, FPartitionObject: OleVariant;
begin
FStartTime:=Now;
CoInitialize(nil);
try
try
FSuccess:=False;
while not TryEnterCriticalSection(FConnectSection)
do
Sleep(500);
try
FServerObject:=CreateOLEObject('DSO.Server');
FServerObject.Connect(FServerName);
FDatabaseObject:=FServerObject.MDStores.Item(FDatabaseName);
FCubeObject:=FDatabaseObject.MDStores.Item(FCubeName);
FPartitionObject:=FCubeObject.MDStores.Item(FPartitionName);
finally
LeaveCriticalSection(FConnectSection);
end;
FPartitionObject.Process;
FSuccess:=True;
except
on E: Exception do
begin
FErrorMessage:=E.Message;
FSuccess:=False;
end;
end;
finally
CoUninitialize;
FEndTime:=Now;
end;
end;
Thanks a lot!
-MalcolmOne possible issue is that DSO is written in VB and thus it will have
serious threading issues in this environment. This is why the PPU uses
separate processes (rather than threads) to process objects in parallel.
--
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Malcolm Toon" <mtoon@. no-spam.retailsolutions.com> wrote in message
news:uVqYwLvLFHA.1396@.TK2MSFTNGP10.phx.gbl...
> I am using DSO to list all the partitions (> 200) in my cube and then do a
> threaded process of these partitions.
> Thres questions:
> 1) I am using a grid to show all the partitions, whether they have been
> processed or not and what their Estimated rows are. During population of
> this grid (basically just iterating Cube.MDStores[x]), 9 times out of
10 I
> get this random divide by zero error. I'm definately not causing this.
> This is my loop:
> for i:=1 to FCube.MDStores.Count do
> begin
> FPartition:=FCube.MDStores.Item(i);
> FEstimatedRows:=FPartition.EstimatedRows;
> sgPartitionList.Cells[0,i]:=FPartition.Name;
> if FPartition.State = olapStateCurrent then
> sgPartitionList.Cells[1,i]:='Processed'
> else
> sgPartitionList.Cells[1,i]:='No';
> sgPartitionList.Cells[2,i]:=IntToStr(FEstimatedRows);
> // Brain fart mentioned below goes here.
> end;
> Interestingly enough (2AM brain fart), I added this:
> if i mod 12 = 0 then
> begin
> Application.ProcessMessages;
> Sleep(500);
> Application.ProcessMessages;
> end;
> to the loop (every 12 iterations, sleep 500 ms after processing all system
> messages in the queue) and it works. Any idea why?
>
> 2) This same behavior presents itself during partition creation. At 225
> partitions (without the message processing and pause), the OLE system
kicks
> back divide by zero errors or Access Violations. I've added the pause and
> ProcessMessages to the creation loop and it's fine, but it worries me. Is
> DSO really that flaky or am I missing something?
> 3) During partition process: I have a multi-threaded approach. I call
> CoInitialize (to create a new OLE session because apparently DSO is not
> threaded correctly) create a connection to the server, the database, the
> cube and the partitions and then call FPartitionObject.Process;
> This actually works great, but my question is, sporadically, the
processing
> just stops. I check the data directory and there won't have been any
> updates to the files in several hours (as opposed to minutes when the
> processing is working) and the CPU usage will be almost nil. I kill the
> application, I also have to restart the OLAP service. There is no pattern
> here, sometimes it'll process the whole cube (> 200 partitions), sometimes
> it'll die at 50, sometimes 100, sometimes 4. Any Ideas? I've included my
> Delphi source for the meat of the thread below.
> procedure TPartitionProcessThread.Execute;
> var
> FServerObject, FDatabaseObject, FCubeObject, FPartitionObject:
OleVariant;
> begin
> FStartTime:=Now;
> CoInitialize(nil);
> try
> try
> FSuccess:=False;
> while not TryEnterCriticalSection(FConnectSection)
do
> Sleep(500);
> try
> FServerObject:=CreateOLEObject('DSO.Server');
> FServerObject.Connect(FServerName);
> FDatabaseObject:=FServerObject.MDStores.Item(FDatabaseName);
> FCubeObject:=FDatabaseObject.MDStores.Item(FCubeName);
> FPartitionObject:=FCubeObject.MDStores.Item(FPartitionName);
> finally
> LeaveCriticalSection(FConnectSection);
> end;
> FPartitionObject.Process;
> FSuccess:=True;
> except
> on E: Exception do
> begin
> FErrorMessage:=E.Message;
> FSuccess:=False;
> end;
> end;
> finally
> CoUninitialize;
> FEndTime:=Now;
> end;
> end;
>
> Thanks a lot!
> -Malcolm
>|||What about AS2005? Will it have the same problems? We're still in R&D,
Proof of Concept phase, so we're open to starting with AS2005 when we move
to actual development and production, but will it have the same problem?
Should I start coding our solutions to really be different EXEs? Is there
any alternative to DSO? Is there another API of some sort? Some way to
mimic what DSO does.
Thanks again for the help!
-Malcolm
"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message
news:%23Go1Kh%23LFHA.3788@.tk2msftngp13.phx.gbl...
> One possible issue is that DSO is written in VB and thus it will have
> serious threading issues in this environment. This is why the PPU uses
> separate processes (rather than threads) to process objects in parallel.
> --
> Dave Wickert [MSFT]
> dwickert@.online.microsoft.com
> Program Manager
> BI SystemsTeam
> SQL BI Product Unit (Analysis Services)
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Malcolm Toon" <mtoon@. no-spam.retailsolutions.com> wrote in message
> news:uVqYwLvLFHA.1396@.TK2MSFTNGP10.phx.gbl...
a[vbcol=seagreen]
of[vbcol=seagreen]
I[vbcol=seagreen]
system[vbcol=seagreen]
> kicks
and[vbcol=seagreen]
Is[vbcol=seagreen]
> processing
pattern[vbcol=seagreen]
sometimes[vbcol=seagreen]
my[vbcol=seagreen]
> OleVariant;
>|||SQL 2005's management APIs (AMO) are all written in managed code. They are
totally thread-safe.
--
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Malcolm Toon" <mtoon@. no-spam.retailsolutions.com> wrote in message
news:uo2aJ6%23LFHA.244@.tk2msftngp13.phx.gbl...
> What about AS2005? Will it have the same problems? We're still in R&D,
> Proof of Concept phase, so we're open to starting with AS2005 when we move
> to actual development and production, but will it have the same problem?
> Should I start coding our solutions to really be different EXEs? Is there
> any alternative to DSO? Is there another API of some sort? Some way to
> mimic what DSO does.
> Thanks again for the help!
> -Malcolm
> "Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message
> news:%23Go1Kh%23LFHA.3788@.tk2msftngp13.phx.gbl...
> rights.
do[vbcol=seagreen]
> a
been[vbcol=seagreen]
> of
10[vbcol=seagreen]
> I
this.[vbcol=seagreen]
> system
225[vbcol=seagreen]
> and
> Is
not[vbcol=seagreen]
the[vbcol=seagreen]
the[vbcol=seagreen]
> pattern
> sometimes
included[vbcol=seagreen]
> my
>