datawindow vs datastore performance #2

I've run into a problem that may be distinct to a particular client 
machine and/or network but it raised an interesting question while doing 
a quick test......

I do a retrieve on a datawindow with setredraw false and the retrieve 
time is horrible(8 minutes for 4500 records). Certainly unacceptable for 
any machine. As a quick test I created a ds with the same dwo and same 
arguments and the client said it retrieved quickly as expected(1 sec).

My question is even with setredraw false is there other processing going 
on inside a dw that does not on a ds? I have no dw events that would 
trigger any external processes.

The dwo does have a few dddw's and my spidy sense tells me this may be 
the culprit even with redraw off. That the ds ignores the dddw's 
perhaps?  I haven't had a chance to do comparative tests with other 
machines yet. I'm using 10.5.2 and MSS2005 with ODBC

Can anyone shed some light on this?

Thanks
0
300ZX
12/22/2010 5:08:58 PM
sybase.powerbuilder.datawindow 28057 articles. 4 followers. Follow

22 Replies
702 Views

Similar Articles

[PageSpeed] 9

Some random thoughts...
Anything in the RetrieveRow event of the DW? Even a comment disables 
buffering.
I'm pretty sure DDDW would have to be retrieved in a DS, so the display 
column is available for printing.
Successive retrieves often perform better on the 2nd and following 
because of cached data on the server and other internal stuff that gets 
"warmed up".
There was a total eclipse of the moon yesterday ;-)

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 12/22/2010 12:08 PM, 300ZX wrote:
> I've run into a problem that may be distinct to a particular client
> machine and/or network but it raised an interesting question while doing
> a quick test......
>
> I do a retrieve on a datawindow with setredraw false and the retrieve
> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
> any machine. As a quick test I created a ds with the same dwo and same
> arguments and the client said it retrieved quickly as expected(1 sec).
>
> My question is even with setredraw false is there other processing going
> on inside a dw that does not on a ds? I have no dw events that would
> trigger any external processes.
>
> The dwo does have a few dddw's and my spidy sense tells me this may be
> the culprit even with redraw off. That the ds ignores the dddw's
> perhaps? I haven't had a chance to do comparative tests with other
> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>
> Can anyone shed some light on this?
>
> Thanks
0
Jerry
12/22/2010 5:27:11 PM
Hi ZX;

    Please check to see if their is any code on the RetrieveRow event of 
your DC. This can slow the Retrieve down to a crawl.

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"300ZX"  wrote in message news:4d1230aa@forums-1-dub...

I've run into a problem that may be distinct to a particular client
machine and/or network but it raised an interesting question while doing
a quick test......

I do a retrieve on a datawindow with setredraw false and the retrieve
time is horrible(8 minutes for 4500 records). Certainly unacceptable for
any machine. As a quick test I created a ds with the same dwo and same
arguments and the client said it retrieved quickly as expected(1 sec).

My question is even with setredraw false is there other processing going
on inside a dw that does not on a ds? I have no dw events that would
trigger any external processes.

The dwo does have a few dddw's and my spidy sense tells me this may be
the culprit even with redraw off. That the ds ignores the dddw's
perhaps?  I haven't had a chance to do comparative tests with other
machines yet. I'm using 10.5.2 and MSS2005 with ODBC

Can anyone shed some light on this?

Thanks 

0
Chris
12/22/2010 5:28:05 PM
Put a trace on your database connection to make sure both versions are 
executing the same SQL, including SQL for dddws. (You can also make sure 
the back end is responding consistently-- a way to check Jerry's thought 
of db query caching.)



On 12/22/2010 11:08 AM, 300ZX wrote:
> I've run into a problem that may be distinct to a particular client
> machine and/or network but it raised an interesting question while doing
> a quick test......
>
> I do a retrieve on a datawindow with setredraw false and the retrieve
> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
> any machine. As a quick test I created a ds with the same dwo and same
> arguments and the client said it retrieved quickly as expected(1 sec).
>
> My question is even with setredraw false is there other processing going
> on inside a dw that does not on a ds? I have no dw events that would
> trigger any external processes.
>
> The dwo does have a few dddw's and my spidy sense tells me this may be
> the culprit even with redraw off. That the ds ignores the dddw's
> perhaps? I haven't had a chance to do comparative tests with other
> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>
> Can anyone shed some light on this?
>
> Thanks
0
Jason
12/22/2010 5:36:47 PM
nothing in the retrieverow, but can you explain why a comment disables 
buffering? Would that be true of other event such as rowfocuschanged?

On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
> Some random thoughts...
> Anything in the RetrieveRow event of the DW? Even a comment disables
> buffering.
> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
> column is available for printing.
> Successive retrieves often perform better on the 2nd and following
> because of cached data on the server and other internal stuff that gets
> "warmed up".
> There was a total eclipse of the moon yesterday ;-)
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 12:08 PM, 300ZX wrote:
>> I've run into a problem that may be distinct to a particular client
>> machine and/or network but it raised an interesting question while doing
>> a quick test......
>>
>> I do a retrieve on a datawindow with setredraw false and the retrieve
>> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
>> any machine. As a quick test I created a ds with the same dwo and same
>> arguments and the client said it retrieved quickly as expected(1 sec).
>>
>> My question is even with setredraw false is there other processing going
>> on inside a dw that does not on a ds? I have no dw events that would
>> trigger any external processes.
>>
>> The dwo does have a few dddw's and my spidy sense tells me this may be
>> the culprit even with redraw off. That the ds ignores the dddw's
>> perhaps? I haven't had a chance to do comparative tests with other
>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>
>> Can anyone shed some light on this?
>>
>> Thanks

0
300ZX
12/22/2010 5:48:23 PM
BTW: That goes for any ancestor code as well in the RR event.


"300ZX"  wrote in message news:4d1239e7$1@forums-1-dub... 

nothing in the retrieverow, but can you explain why a comment disables 
buffering? Would that be true of other event such as rowfocuschanged?

On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
> Some random thoughts...
> Anything in the RetrieveRow event of the DW? Even a comment disables
> buffering.
> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
> column is available for printing.
> Successive retrieves often perform better on the 2nd and following
> because of cached data on the server and other internal stuff that gets
> "warmed up".
> There was a total eclipse of the moon yesterday ;-)
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 12:08 PM, 300ZX wrote:
>> I've run into a problem that may be distinct to a particular client
>> machine and/or network but it raised an interesting question while doing
>> a quick test......
>>
>> I do a retrieve on a datawindow with setredraw false and the retrieve
>> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
>> any machine. As a quick test I created a ds with the same dwo and same
>> arguments and the client said it retrieved quickly as expected(1 sec).
>>
>> My question is even with setredraw false is there other processing going
>> on inside a dw that does not on a ds? I have no dw events that would
>> trigger any external processes.
>>
>> The dwo does have a few dddw's and my spidy sense tells me this may be
>> the culprit even with redraw off. That the ds ignores the dddw's
>> perhaps? I haven't had a chance to do comparative tests with other
>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>
>> Can anyone shed some light on this?
>>
>> Thanks
0
Chris
12/22/2010 5:59:18 PM
It will be a few days before I have a chance to revisit it but will try that

On 22/12/10 12:36 PM, Jason 'Bug' Fenter [TeamSybase] wrote:
> Put a trace on your database connection to make sure both versions are
> executing the same SQL, including SQL for dddws. (You can also make sure
> the back end is responding consistently-- a way to check Jerry's thought
> of db query caching.)
>
>
>
> On 12/22/2010 11:08 AM, 300ZX wrote:
>> I've run into a problem that may be distinct to a particular client
>> machine and/or network but it raised an interesting question while doing
>> a quick test......
>>
>> I do a retrieve on a datawindow with setredraw false and the retrieve
>> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
>> any machine. As a quick test I created a ds with the same dwo and same
>> arguments and the client said it retrieved quickly as expected(1 sec).
>>
>> My question is even with setredraw false is there other processing going
>> on inside a dw that does not on a ds? I have no dw events that would
>> trigger any external processes.
>>
>> The dwo does have a few dddw's and my spidy sense tells me this may be
>> the culprit even with redraw off. That the ds ignores the dddw's
>> perhaps? I haven't had a chance to do comparative tests with other
>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>
>> Can anyone shed some light on this?
>>
>> Thanks

0
300ZX
12/22/2010 6:17:25 PM
Speculation, but it's easy for code in the DW engine to tell that the 
script exists and less so to parse it to determine if it actually does 
anything. RowFocusChanged wouldn't fire until the retrieve is done and 
focus is set to the first row.
I don't think other scripts would effect buffering - RetrieveRow fires 
after each row is retrieved so it requires each row to be fetched 
individually rather that in a block. Each interaction with the DBMS 
requires several "handshaking" messages to pass across the network, 
hence the performance hit.

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 12/22/2010 12:48 PM, 300ZX wrote:
> nothing in the retrieverow, but can you explain why a comment disables
> buffering? Would that be true of other event such as rowfocuschanged?
>
> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>> Some random thoughts...
>> Anything in the RetrieveRow event of the DW? Even a comment disables
>> buffering.
>> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
>> column is available for printing.
>> Successive retrieves often perform better on the 2nd and following
>> because of cached data on the server and other internal stuff that gets
>> "warmed up".
>> There was a total eclipse of the moon yesterday ;-)
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>> I've run into a problem that may be distinct to a particular client
>>> machine and/or network but it raised an interesting question while doing
>>> a quick test......
>>>
>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable for
>>> any machine. As a quick test I created a ds with the same dwo and same
>>> arguments and the client said it retrieved quickly as expected(1 sec).
>>>
>>> My question is even with setredraw false is there other processing going
>>> on inside a dw that does not on a ds? I have no dw events that would
>>> trigger any external processes.
>>>
>>> The dwo does have a few dddw's and my spidy sense tells me this may be
>>> the culprit even with redraw off. That the ds ignores the dddw's
>>> perhaps? I haven't had a chance to do comparative tests with other
>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>
>>> Can anyone shed some light on this?
>>>
>>> Thanks
>
0
Jerry
12/22/2010 9:07:15 PM
I was under the assumption all comments(regardless of where they reside) 
were ignored at compile time and therefore were harmless....learn 
something new everyday

On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
> Speculation, but it's easy for code in the DW engine to tell that the
> script exists and less so to parse it to determine if it actually does
> anything. RowFocusChanged wouldn't fire until the retrieve is done and
> focus is set to the first row.
> I don't think other scripts would effect buffering - RetrieveRow fires
> after each row is retrieved so it requires each row to be fetched
> individually rather that in a block. Each interaction with the DBMS
> requires several "handshaking" messages to pass across the network,
> hence the performance hit.
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 12:48 PM, 300ZX wrote:
>> nothing in the retrieverow, but can you explain why a comment disables
>> buffering? Would that be true of other event such as rowfocuschanged?
>>
>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>> Some random thoughts...
>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>> buffering.
>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
>>> column is available for printing.
>>> Successive retrieves often perform better on the 2nd and following
>>> because of cached data on the server and other internal stuff that gets
>>> "warmed up".
>>> There was a total eclipse of the moon yesterday ;-)
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>> I've run into a problem that may be distinct to a particular client
>>>> machine and/or network but it raised an interesting question while
>>>> doing
>>>> a quick test......
>>>>
>>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>> for
>>>> any machine. As a quick test I created a ds with the same dwo and same
>>>> arguments and the client said it retrieved quickly as expected(1 sec).
>>>>
>>>> My question is even with setredraw false is there other processing
>>>> going
>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>> trigger any external processes.
>>>>
>>>> The dwo does have a few dddw's and my spidy sense tells me this may be
>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>
>>>> Can anyone shed some light on this?
>>>>
>>>> Thanks
>>

0
300ZX
12/22/2010 9:27:04 PM
The comment itself is discarded. However, having the comment exist in 
the first place requires adding the event signature to the object. To 
see this:

Create a nonvisual object. Add a custom event to it.
Create a descendant of this object with no code in it. Save the descendant.
Now view the source of the descendant. You will not see any reference to 
the custom event.
Close that and reopen the descendant in the painter. Add a comment to 
the custom event. Save.
View the source of the descendant again. You'll now see a block of code 
for the custom event.

At compile time, the comment itself will get stripped away. However, the 
block of code defining the custom event will still be there, thus 
forcing the runtime to call it on a per-row basis which totally trashes 
the network batching you would have otherwise seen (as Jerry described).



On 12/22/2010 3:27 PM, 300ZX wrote:
> I was under the assumption all comments(regardless of where they reside)
> were ignored at compile time and therefore were harmless....learn
> something new everyday
>
> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>> Speculation, but it's easy for code in the DW engine to tell that the
>> script exists and less so to parse it to determine if it actually does
>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>> focus is set to the first row.
>> I don't think other scripts would effect buffering - RetrieveRow fires
>> after each row is retrieved so it requires each row to be fetched
>> individually rather that in a block. Each interaction with the DBMS
>> requires several "handshaking" messages to pass across the network,
>> hence the performance hit.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>> nothing in the retrieverow, but can you explain why a comment disables
>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>
>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Some random thoughts...
>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>> buffering.
>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
>>>> column is available for printing.
>>>> Successive retrieves often perform better on the 2nd and following
>>>> because of cached data on the server and other internal stuff that gets
>>>> "warmed up".
>>>> There was a total eclipse of the moon yesterday ;-)
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>> I've run into a problem that may be distinct to a particular client
>>>>> machine and/or network but it raised an interesting question while
>>>>> doing
>>>>> a quick test......
>>>>>
>>>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>>> for
>>>>> any machine. As a quick test I created a ds with the same dwo and same
>>>>> arguments and the client said it retrieved quickly as expected(1 sec).
>>>>>
>>>>> My question is even with setredraw false is there other processing
>>>>> going
>>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>>> trigger any external processes.
>>>>>
>>>>> The dwo does have a few dddw's and my spidy sense tells me this may be
>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>
>>>>> Can anyone shed some light on this?
>>>>>
>>>>> Thanks
>>>
>
0
Jason
12/22/2010 10:30:34 PM
Just for grins I added a comment to a DW's RetrieveRow script and looked 
at the source. It generated

event retrieverow;// comment
end event

and I strongly suspect that the event declaration, which was not there 
before I added the comment, is what the DW engine is looking at.

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 12/22/2010 4:27 PM, 300ZX wrote:
> I was under the assumption all comments(regardless of where they reside)
> were ignored at compile time and therefore were harmless....learn
> something new everyday
>
> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>> Speculation, but it's easy for code in the DW engine to tell that the
>> script exists and less so to parse it to determine if it actually does
>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>> focus is set to the first row.
>> I don't think other scripts would effect buffering - RetrieveRow fires
>> after each row is retrieved so it requires each row to be fetched
>> individually rather that in a block. Each interaction with the DBMS
>> requires several "handshaking" messages to pass across the network,
>> hence the performance hit.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>> nothing in the retrieverow, but can you explain why a comment disables
>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>
>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Some random thoughts...
>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>> buffering.
>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
>>>> column is available for printing.
>>>> Successive retrieves often perform better on the 2nd and following
>>>> because of cached data on the server and other internal stuff that gets
>>>> "warmed up".
>>>> There was a total eclipse of the moon yesterday ;-)
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>> I've run into a problem that may be distinct to a particular client
>>>>> machine and/or network but it raised an interesting question while
>>>>> doing
>>>>> a quick test......
>>>>>
>>>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>>> for
>>>>> any machine. As a quick test I created a ds with the same dwo and same
>>>>> arguments and the client said it retrieved quickly as expected(1 sec).
>>>>>
>>>>> My question is even with setredraw false is there other processing
>>>>> going
>>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>>> trigger any external processes.
>>>>>
>>>>> The dwo does have a few dddw's and my spidy sense tells me this may be
>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>
>>>>> Can anyone shed some light on this?
>>>>>
>>>>> Thanks
>>>
>
0
Jerry
12/22/2010 10:32:13 PM
Yes, make sure that the PB IDE does *not* show a paper icon on the RR event 
of any colour. Otherwise, you could indeed have a blank line or rogue 
comment somewhere that forces the slow performance on each row fetched from 
the RS buffer.



"Jason 'Bug' Fenter [TeamSybase]"  wrote in message 
news:4d127c0a$1@forums-1-dub...

The comment itself is discarded. However, having the comment exist in
the first place requires adding the event signature to the object. To
see this:

Create a nonvisual object. Add a custom event to it.
Create a descendant of this object with no code in it. Save the descendant.
Now view the source of the descendant. You will not see any reference to
the custom event.
Close that and reopen the descendant in the painter. Add a comment to
the custom event. Save.
View the source of the descendant again. You'll now see a block of code
for the custom event.

At compile time, the comment itself will get stripped away. However, the
block of code defining the custom event will still be there, thus
forcing the runtime to call it on a per-row basis which totally trashes
the network batching you would have otherwise seen (as Jerry described).



On 12/22/2010 3:27 PM, 300ZX wrote:
> I was under the assumption all comments(regardless of where they reside)
> were ignored at compile time and therefore were harmless....learn
> something new everyday
>
> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>> Speculation, but it's easy for code in the DW engine to tell that the
>> script exists and less so to parse it to determine if it actually does
>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>> focus is set to the first row.
>> I don't think other scripts would effect buffering - RetrieveRow fires
>> after each row is retrieved so it requires each row to be fetched
>> individually rather that in a block. Each interaction with the DBMS
>> requires several "handshaking" messages to pass across the network,
>> hence the performance hit.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>> nothing in the retrieverow, but can you explain why a comment disables
>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>
>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Some random thoughts...
>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>> buffering.
>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the display
>>>> column is available for printing.
>>>> Successive retrieves often perform better on the 2nd and following
>>>> because of cached data on the server and other internal stuff that gets
>>>> "warmed up".
>>>> There was a total eclipse of the moon yesterday ;-)
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>> I've run into a problem that may be distinct to a particular client
>>>>> machine and/or network but it raised an interesting question while
>>>>> doing
>>>>> a quick test......
>>>>>
>>>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>>> for
>>>>> any machine. As a quick test I created a ds with the same dwo and same
>>>>> arguments and the client said it retrieved quickly as expected(1 sec).
>>>>>
>>>>> My question is even with setredraw false is there other processing
>>>>> going
>>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>>> trigger any external processes.
>>>>>
>>>>> The dwo does have a few dddw's and my spidy sense tells me this may be
>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>
>>>>> Can anyone shed some light on this?
>>>>>
>>>>> Thanks
>>>
> 

0
Chris
12/22/2010 10:35:04 PM
Understood but in my case I have nothing in the RR event...other common 
events yes


On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
> Just for grins I added a comment to a DW's RetrieveRow script and looked
> at the source. It generated
>
> event retrieverow;// comment
> end event
>
> and I strongly suspect that the event declaration, which was not there
> before I added the comment, is what the DW engine is looking at.
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 4:27 PM, 300ZX wrote:
>> I was under the assumption all comments(regardless of where they reside)
>> were ignored at compile time and therefore were harmless....learn
>> something new everyday
>>
>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>> Speculation, but it's easy for code in the DW engine to tell that the
>>> script exists and less so to parse it to determine if it actually does
>>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>>> focus is set to the first row.
>>> I don't think other scripts would effect buffering - RetrieveRow fires
>>> after each row is retrieved so it requires each row to be fetched
>>> individually rather that in a block. Each interaction with the DBMS
>>> requires several "handshaking" messages to pass across the network,
>>> hence the performance hit.
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>> nothing in the retrieverow, but can you explain why a comment disables
>>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>>
>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>> Some random thoughts...
>>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>>> buffering.
>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>> display
>>>>> column is available for printing.
>>>>> Successive retrieves often perform better on the 2nd and following
>>>>> because of cached data on the server and other internal stuff that
>>>>> gets
>>>>> "warmed up".
>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>
>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>> Product Enhancement Requests:
>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>
>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>> I've run into a problem that may be distinct to a particular client
>>>>>> machine and/or network but it raised an interesting question while
>>>>>> doing
>>>>>> a quick test......
>>>>>>
>>>>>> I do a retrieve on a datawindow with setredraw false and the retrieve
>>>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>>>> for
>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>> same
>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>> sec).
>>>>>>
>>>>>> My question is even with setredraw false is there other processing
>>>>>> going
>>>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>>>> trigger any external processes.
>>>>>>
>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>> may be
>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>
>>>>>> Can anyone shed some light on this?
>>>>>>
>>>>>> Thanks
>>>>
>>

0
300ZX
12/23/2010 1:07:41 AM
That probably takes buffering out of the situation.
Try two successive retrieves to see if DBMS caching is a factor.
I'd also try to find out if painting the DW is the factor - how long 
between RetrieveEnd and visibility? I'm pretty sure a DS does not get 
painted until/unless you print it.
How about retrieve into a DS and ShareData? That would require that the 
DDDW be manually retrieved, it's not automatic as with a DW retrieve. 
DDDW retrieves can be time-consuming. I recollect a DW that simulated a 
Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of 
them! In that case we retrieved the codes into a DS and shared it with 
the DataWindowChild for each DDDW, saving a lot of time.

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 12/22/2010 8:07 PM, 300ZX wrote:
> Understood but in my case I have nothing in the RR event...other common
> events yes
>
>
> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>> Just for grins I added a comment to a DW's RetrieveRow script and looked
>> at the source. It generated
>>
>> event retrieverow;// comment
>> end event
>>
>> and I strongly suspect that the event declaration, which was not there
>> before I added the comment, is what the DW engine is looking at.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>> I was under the assumption all comments(regardless of where they reside)
>>> were ignored at compile time and therefore were harmless....learn
>>> something new everyday
>>>
>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Speculation, but it's easy for code in the DW engine to tell that the
>>>> script exists and less so to parse it to determine if it actually does
>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>>>> focus is set to the first row.
>>>> I don't think other scripts would effect buffering - RetrieveRow fires
>>>> after each row is retrieved so it requires each row to be fetched
>>>> individually rather that in a block. Each interaction with the DBMS
>>>> requires several "handshaking" messages to pass across the network,
>>>> hence the performance hit.
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>> nothing in the retrieverow, but can you explain why a comment disables
>>>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>>>
>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>> Some random thoughts...
>>>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>>>> buffering.
>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>> display
>>>>>> column is available for printing.
>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>> because of cached data on the server and other internal stuff that
>>>>>> gets
>>>>>> "warmed up".
>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>
>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>> Product Enhancement Requests:
>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>
>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>> I've run into a problem that may be distinct to a particular client
>>>>>>> machine and/or network but it raised an interesting question while
>>>>>>> doing
>>>>>>> a quick test......
>>>>>>>
>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>> retrieve
>>>>>>> time is horrible(8 minutes for 4500 records). Certainly unacceptable
>>>>>>> for
>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>> same
>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>> sec).
>>>>>>>
>>>>>>> My question is even with setredraw false is there other processing
>>>>>>> going
>>>>>>> on inside a dw that does not on a ds? I have no dw events that would
>>>>>>> trigger any external processes.
>>>>>>>
>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>> may be
>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>
>>>>>>> Can anyone shed some light on this?
>>>>>>>
>>>>>>> Thanks
>>>>>
>>>
>
0
Jerry
12/23/2010 3:06:19 AM
I appreciate all your thoughts on this

I had the idea of ds to sharedata already tucked away in my head when I 
saw initially how quick the ds retrieved...however you and Jason may be 
correct in that it is just caching, but of course i'm getting ahead of 
myself as testing is far from complete.

Not sure on the time from retrieve end to vis but that is another good 
question. It's just a bad time of year to be doing remote tests with the 
clients as most are on holidays but I'll keep you posted on what I discover

thanks again to all and merry christmas

On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
> That probably takes buffering out of the situation.
> Try two successive retrieves to see if DBMS caching is a factor.
> I'd also try to find out if painting the DW is the factor - how long
> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
> painted until/unless you print it.
> How about retrieve into a DS and ShareData? That would require that the
> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
> them! In that case we retrieved the codes into a DS and shared it with
> the DataWindowChild for each DDDW, saving a lot of time.
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 8:07 PM, 300ZX wrote:
>> Understood but in my case I have nothing in the RR event...other common
>> events yes
>>
>>
>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>> Just for grins I added a comment to a DW's RetrieveRow script and looked
>>> at the source. It generated
>>>
>>> event retrieverow;// comment
>>> end event
>>>
>>> and I strongly suspect that the event declaration, which was not there
>>> before I added the comment, is what the DW engine is looking at.
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>> I was under the assumption all comments(regardless of where they
>>>> reside)
>>>> were ignored at compile time and therefore were harmless....learn
>>>> something new everyday
>>>>
>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>> Speculation, but it's easy for code in the DW engine to tell that the
>>>>> script exists and less so to parse it to determine if it actually does
>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>>>>> focus is set to the first row.
>>>>> I don't think other scripts would effect buffering - RetrieveRow fires
>>>>> after each row is retrieved so it requires each row to be fetched
>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>> requires several "handshaking" messages to pass across the network,
>>>>> hence the performance hit.
>>>>>
>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>> Product Enhancement Requests:
>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>
>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>> disables
>>>>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>>>>
>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>> Some random thoughts...
>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>>>>> buffering.
>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>> display
>>>>>>> column is available for printing.
>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>> gets
>>>>>>> "warmed up".
>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>
>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>> Product Enhancement Requests:
>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>
>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>> I've run into a problem that may be distinct to a particular client
>>>>>>>> machine and/or network but it raised an interesting question while
>>>>>>>> doing
>>>>>>>> a quick test......
>>>>>>>>
>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>> retrieve
>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>> unacceptable
>>>>>>>> for
>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>> same
>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>> sec).
>>>>>>>>
>>>>>>>> My question is even with setredraw false is there other processing
>>>>>>>> going
>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>> would
>>>>>>>> trigger any external processes.
>>>>>>>>
>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>> may be
>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>
>>>>>>>> Can anyone shed some light on this?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>
>>>>
>>

0
300ZX
12/23/2010 3:42:45 AM
Hi;

   What I normally do in this case is ...

1) Disable the Retrieve on the DC
2) Hide the DC
3) Add another DC from the System class beside the current one.
4) Use the same DWO as in the real DC
5) Use the SetRedraw ( ) to turn off visualization
6) Run a Retrieve ( ) on the temporary DC to check its performance.

If the test DC performs like the original one - look for problems in the DB 
connection and SQL. If the test DC works like the DS - then go back and 
analyze the original DC's scripts.

HTH

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"300ZX"  wrote in message news:4d12c535@forums-1-dub...

I appreciate all your thoughts on this

I had the idea of ds to sharedata already tucked away in my head when I
saw initially how quick the ds retrieved...however you and Jason may be
correct in that it is just caching, but of course i'm getting ahead of
myself as testing is far from complete.

Not sure on the time from retrieve end to vis but that is another good
question. It's just a bad time of year to be doing remote tests with the
clients as most are on holidays but I'll keep you posted on what I discover

thanks again to all and merry christmas

On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
> That probably takes buffering out of the situation.
> Try two successive retrieves to see if DBMS caching is a factor.
> I'd also try to find out if painting the DW is the factor - how long
> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
> painted until/unless you print it.
> How about retrieve into a DS and ShareData? That would require that the
> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
> them! In that case we retrieved the codes into a DS and shared it with
> the DataWindowChild for each DDDW, saving a lot of time.
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/22/2010 8:07 PM, 300ZX wrote:
>> Understood but in my case I have nothing in the RR event...other common
>> events yes
>>
>>
>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>> Just for grins I added a comment to a DW's RetrieveRow script and looked
>>> at the source. It generated
>>>
>>> event retrieverow;// comment
>>> end event
>>>
>>> and I strongly suspect that the event declaration, which was not there
>>> before I added the comment, is what the DW engine is looking at.
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>> I was under the assumption all comments(regardless of where they
>>>> reside)
>>>> were ignored at compile time and therefore were harmless....learn
>>>> something new everyday
>>>>
>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>> Speculation, but it's easy for code in the DW engine to tell that the
>>>>> script exists and less so to parse it to determine if it actually does
>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done and
>>>>> focus is set to the first row.
>>>>> I don't think other scripts would effect buffering - RetrieveRow fires
>>>>> after each row is retrieved so it requires each row to be fetched
>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>> requires several "handshaking" messages to pass across the network,
>>>>> hence the performance hit.
>>>>>
>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>> Product Enhancement Requests:
>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>
>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>> disables
>>>>>> buffering? Would that be true of other event such as rowfocuschanged?
>>>>>>
>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>> Some random thoughts...
>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment disables
>>>>>>> buffering.
>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>> display
>>>>>>> column is available for printing.
>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>> gets
>>>>>>> "warmed up".
>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>
>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>> Product Enhancement Requests:
>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>
>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>> I've run into a problem that may be distinct to a particular client
>>>>>>>> machine and/or network but it raised an interesting question while
>>>>>>>> doing
>>>>>>>> a quick test......
>>>>>>>>
>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>> retrieve
>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>> unacceptable
>>>>>>>> for
>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>> same
>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>> sec).
>>>>>>>>
>>>>>>>> My question is even with setredraw false is there other processing
>>>>>>>> going
>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>> would
>>>>>>>> trigger any external processes.
>>>>>>>>
>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>> may be
>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>
>>>>>>>> Can anyone shed some light on this?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>
>>>>
>> 

0
Chris
12/23/2010 3:17:48 PM
actually I am compiling a list of sequential tests to determine the 
optimum approach and that is one of them

another thought I had was to drop the dddw and opt for joins instead but 
not sure what the tradeoff curve would look like


On 23/12/10 10:17 AM, Chris Pollach wrote:
> Hi;
>
> What I normally do in this case is ...
>
> 1) Disable the Retrieve on the DC
> 2) Hide the DC
> 3) Add another DC from the System class beside the current one.
> 4) Use the same DWO as in the real DC
> 5) Use the SetRedraw ( ) to turn off visualization
> 6) Run a Retrieve ( ) on the temporary DC to check its performance.
>
> If the test DC performs like the original one - look for problems in the
> DB connection and SQL. If the test DC works like the DS - then go back
> and analyze the original DC's scripts.
>
> HTH
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "300ZX" wrote in message news:4d12c535@forums-1-dub...
>
> I appreciate all your thoughts on this
>
> I had the idea of ds to sharedata already tucked away in my head when I
> saw initially how quick the ds retrieved...however you and Jason may be
> correct in that it is just caching, but of course i'm getting ahead of
> myself as testing is far from complete.
>
> Not sure on the time from retrieve end to vis but that is another good
> question. It's just a bad time of year to be doing remote tests with the
> clients as most are on holidays but I'll keep you posted on what I discover
>
> thanks again to all and merry christmas
>
> On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
>> That probably takes buffering out of the situation.
>> Try two successive retrieves to see if DBMS caching is a factor.
>> I'd also try to find out if painting the DW is the factor - how long
>> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
>> painted until/unless you print it.
>> How about retrieve into a DS and ShareData? That would require that the
>> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
>> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
>> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
>> them! In that case we retrieved the codes into a DS and shared it with
>> the DataWindowChild for each DDDW, saving a lot of time.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 8:07 PM, 300ZX wrote:
>>> Understood but in my case I have nothing in the RR event...other common
>>> events yes
>>>
>>>
>>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Just for grins I added a comment to a DW's RetrieveRow script and
>>>> looked
>>>> at the source. It generated
>>>>
>>>> event retrieverow;// comment
>>>> end event
>>>>
>>>> and I strongly suspect that the event declaration, which was not there
>>>> before I added the comment, is what the DW engine is looking at.
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>>> I was under the assumption all comments(regardless of where they
>>>>> reside)
>>>>> were ignored at compile time and therefore were harmless....learn
>>>>> something new everyday
>>>>>
>>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>> Speculation, but it's easy for code in the DW engine to tell that the
>>>>>> script exists and less so to parse it to determine if it actually
>>>>>> does
>>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done
>>>>>> and
>>>>>> focus is set to the first row.
>>>>>> I don't think other scripts would effect buffering - RetrieveRow
>>>>>> fires
>>>>>> after each row is retrieved so it requires each row to be fetched
>>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>>> requires several "handshaking" messages to pass across the network,
>>>>>> hence the performance hit.
>>>>>>
>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>> Product Enhancement Requests:
>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>
>>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>>> disables
>>>>>>> buffering? Would that be true of other event such as
>>>>>>> rowfocuschanged?
>>>>>>>
>>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>> Some random thoughts...
>>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment
>>>>>>>> disables
>>>>>>>> buffering.
>>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>>> display
>>>>>>>> column is available for printing.
>>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>>> gets
>>>>>>>> "warmed up".
>>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>>
>>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>>> Product Enhancement Requests:
>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>
>>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>>> I've run into a problem that may be distinct to a particular
>>>>>>>>> client
>>>>>>>>> machine and/or network but it raised an interesting question while
>>>>>>>>> doing
>>>>>>>>> a quick test......
>>>>>>>>>
>>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>>> retrieve
>>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>>> unacceptable
>>>>>>>>> for
>>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>>> same
>>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>>> sec).
>>>>>>>>>
>>>>>>>>> My question is even with setredraw false is there other processing
>>>>>>>>> going
>>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>>> would
>>>>>>>>> trigger any external processes.
>>>>>>>>>
>>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>>> may be
>>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>>
>>>>>>>>> Can anyone shed some light on this?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>
>>>>>
>>>
>

0
300ZX
12/24/2010 12:20:46 AM
Does the DS based DWO have the same DDDW's as the DC based DWO?


"300ZX"  wrote in message news:4d13e75e@forums-1-dub...

actually I am compiling a list of sequential tests to determine the
optimum approach and that is one of them

another thought I had was to drop the dddw and opt for joins instead but
not sure what the tradeoff curve would look like


On 23/12/10 10:17 AM, Chris Pollach wrote:
> Hi;
>
> What I normally do in this case is ...
>
> 1) Disable the Retrieve on the DC
> 2) Hide the DC
> 3) Add another DC from the System class beside the current one.
> 4) Use the same DWO as in the real DC
> 5) Use the SetRedraw ( ) to turn off visualization
> 6) Run a Retrieve ( ) on the temporary DC to check its performance.
>
> If the test DC performs like the original one - look for problems in the
> DB connection and SQL. If the test DC works like the DS - then go back
> and analyze the original DC's scripts.
>
> HTH
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "300ZX" wrote in message news:4d12c535@forums-1-dub...
>
> I appreciate all your thoughts on this
>
> I had the idea of ds to sharedata already tucked away in my head when I
> saw initially how quick the ds retrieved...however you and Jason may be
> correct in that it is just caching, but of course i'm getting ahead of
> myself as testing is far from complete.
>
> Not sure on the time from retrieve end to vis but that is another good
> question. It's just a bad time of year to be doing remote tests with the
> clients as most are on holidays but I'll keep you posted on what I 
> discover
>
> thanks again to all and merry christmas
>
> On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
>> That probably takes buffering out of the situation.
>> Try two successive retrieves to see if DBMS caching is a factor.
>> I'd also try to find out if painting the DW is the factor - how long
>> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
>> painted until/unless you print it.
>> How about retrieve into a DS and ShareData? That would require that the
>> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
>> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
>> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
>> them! In that case we retrieved the codes into a DS and shared it with
>> the DataWindowChild for each DDDW, saving a lot of time.
>>
>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>> Product Enhancement Requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> On 12/22/2010 8:07 PM, 300ZX wrote:
>>> Understood but in my case I have nothing in the RR event...other common
>>> events yes
>>>
>>>
>>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>>> Just for grins I added a comment to a DW's RetrieveRow script and
>>>> looked
>>>> at the source. It generated
>>>>
>>>> event retrieverow;// comment
>>>> end event
>>>>
>>>> and I strongly suspect that the event declaration, which was not there
>>>> before I added the comment, is what the DW engine is looking at.
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>>> I was under the assumption all comments(regardless of where they
>>>>> reside)
>>>>> were ignored at compile time and therefore were harmless....learn
>>>>> something new everyday
>>>>>
>>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>> Speculation, but it's easy for code in the DW engine to tell that the
>>>>>> script exists and less so to parse it to determine if it actually
>>>>>> does
>>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done
>>>>>> and
>>>>>> focus is set to the first row.
>>>>>> I don't think other scripts would effect buffering - RetrieveRow
>>>>>> fires
>>>>>> after each row is retrieved so it requires each row to be fetched
>>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>>> requires several "handshaking" messages to pass across the network,
>>>>>> hence the performance hit.
>>>>>>
>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>> Product Enhancement Requests:
>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>
>>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>>> disables
>>>>>>> buffering? Would that be true of other event such as
>>>>>>> rowfocuschanged?
>>>>>>>
>>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>> Some random thoughts...
>>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment
>>>>>>>> disables
>>>>>>>> buffering.
>>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>>> display
>>>>>>>> column is available for printing.
>>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>>> gets
>>>>>>>> "warmed up".
>>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>>
>>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>>> Product Enhancement Requests:
>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>
>>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>>> I've run into a problem that may be distinct to a particular
>>>>>>>>> client
>>>>>>>>> machine and/or network but it raised an interesting question while
>>>>>>>>> doing
>>>>>>>>> a quick test......
>>>>>>>>>
>>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>>> retrieve
>>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>>> unacceptable
>>>>>>>>> for
>>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>>> same
>>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>>> sec).
>>>>>>>>>
>>>>>>>>> My question is even with setredraw false is there other processing
>>>>>>>>> going
>>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>>> would
>>>>>>>>> trigger any external processes.
>>>>>>>>>
>>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>>> may be
>>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>>> perhaps? I haven't had a chance to do comparative tests with other
>>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>>
>>>>>>>>> Can anyone shed some light on this?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>
>>>>>
>>>
> 

0
Chris
12/24/2010 1:59:38 PM
If you have the key for the DDDW table and it is indexed (or the table 
is small) I would expect an improvement.
Another thought: any grouping or cumulative functions used in computed 
fields? Especially with global function calls? That could cause some 
heavy crunching when the DW is painted.

Report Bugs to Sybase:  http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement

On 12/23/2010 7:20 PM, 300ZX wrote:
> actually I am compiling a list of sequential tests to determine the
> optimum approach and that is one of them
>
> another thought I had was to drop the dddw and opt for joins instead but
> not sure what the tradeoff curve would look like
>
>
> On 23/12/10 10:17 AM, Chris Pollach wrote:
>> Hi;
>>
>> What I normally do in this case is ...
>>
>> 1) Disable the Retrieve on the DC
>> 2) Hide the DC
>> 3) Add another DC from the System class beside the current one.
>> 4) Use the same DWO as in the real DC
>> 5) Use the SetRedraw ( ) to turn off visualization
>> 6) Run a Retrieve ( ) on the temporary DC to check its performance.
>>
>> If the test DC performs like the original one - look for problems in the
>> DB connection and SQL. If the test DC works like the DS - then go back
>> and analyze the original DC's scripts.
>>
>> HTH
>>
>> Regards ... Chris
>> President: OSUG / STD Inc.
>> Blog: http://chrispollach.blogspot.com
>> PBDJ: http://chrispollach.sys-con.com
>> SourceForge: http://sourceforge.net/projects/stdfndclass
>>
>> "300ZX" wrote in message news:4d12c535@forums-1-dub...
>>
>> I appreciate all your thoughts on this
>>
>> I had the idea of ds to sharedata already tucked away in my head when I
>> saw initially how quick the ds retrieved...however you and Jason may be
>> correct in that it is just caching, but of course i'm getting ahead of
>> myself as testing is far from complete.
>>
>> Not sure on the time from retrieve end to vis but that is another good
>> question. It's just a bad time of year to be doing remote tests with the
>> clients as most are on holidays but I'll keep you posted on what I
>> discover
>>
>> thanks again to all and merry christmas
>>
>> On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
>>> That probably takes buffering out of the situation.
>>> Try two successive retrieves to see if DBMS caching is a factor.
>>> I'd also try to find out if painting the DW is the factor - how long
>>> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
>>> painted until/unless you print it.
>>> How about retrieve into a DS and ShareData? That would require that the
>>> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
>>> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
>>> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
>>> them! In that case we retrieved the codes into a DS and shared it with
>>> the DataWindowChild for each DDDW, saving a lot of time.
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 8:07 PM, 300ZX wrote:
>>>> Understood but in my case I have nothing in the RR event...other common
>>>> events yes
>>>>
>>>>
>>>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>>>> Just for grins I added a comment to a DW's RetrieveRow script and
>>>>> looked
>>>>> at the source. It generated
>>>>>
>>>>> event retrieverow;// comment
>>>>> end event
>>>>>
>>>>> and I strongly suspect that the event declaration, which was not there
>>>>> before I added the comment, is what the DW engine is looking at.
>>>>>
>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>> Product Enhancement Requests:
>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>
>>>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>>>> I was under the assumption all comments(regardless of where they
>>>>>> reside)
>>>>>> were ignored at compile time and therefore were harmless....learn
>>>>>> something new everyday
>>>>>>
>>>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>> Speculation, but it's easy for code in the DW engine to tell that
>>>>>>> the
>>>>>>> script exists and less so to parse it to determine if it actually
>>>>>>> does
>>>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done
>>>>>>> and
>>>>>>> focus is set to the first row.
>>>>>>> I don't think other scripts would effect buffering - RetrieveRow
>>>>>>> fires
>>>>>>> after each row is retrieved so it requires each row to be fetched
>>>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>>>> requires several "handshaking" messages to pass across the network,
>>>>>>> hence the performance hit.
>>>>>>>
>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>> Product Enhancement Requests:
>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>
>>>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>>>> disables
>>>>>>>> buffering? Would that be true of other event such as
>>>>>>>> rowfocuschanged?
>>>>>>>>
>>>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>>> Some random thoughts...
>>>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment
>>>>>>>>> disables
>>>>>>>>> buffering.
>>>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>>>> display
>>>>>>>>> column is available for printing.
>>>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>>>> gets
>>>>>>>>> "warmed up".
>>>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>>>
>>>>>>>>> Report Bugs to Sybase:
>>>>>>>>> http://case-express.sybase.com/cx/welcome.do
>>>>>>>>> Product Enhancement Requests:
>>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>>
>>>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>>>> I've run into a problem that may be distinct to a particular
>>>>>>>>>> client
>>>>>>>>>> machine and/or network but it raised an interesting question
>>>>>>>>>> while
>>>>>>>>>> doing
>>>>>>>>>> a quick test......
>>>>>>>>>>
>>>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>>>> retrieve
>>>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>>>> unacceptable
>>>>>>>>>> for
>>>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>>>> same
>>>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>>>> sec).
>>>>>>>>>>
>>>>>>>>>> My question is even with setredraw false is there other
>>>>>>>>>> processing
>>>>>>>>>> going
>>>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>>>> would
>>>>>>>>>> trigger any external processes.
>>>>>>>>>>
>>>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>>>> may be
>>>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>>>> perhaps? I haven't had a chance to do comparative tests with
>>>>>>>>>> other
>>>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>>>
>>>>>>>>>> Can anyone shed some light on this?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>
>>>>>>
>>>>
>>
>
0
Jerry
12/24/2010 6:31:56 PM
Exact same

On 24/12/10 8:59 AM, Chris Pollach wrote:
> Does the DS based DWO have the same DDDW's as the DC based DWO?
>
>
> "300ZX" wrote in message news:4d13e75e@forums-1-dub...
>
> actually I am compiling a list of sequential tests to determine the
> optimum approach and that is one of them
>
> another thought I had was to drop the dddw and opt for joins instead but
> not sure what the tradeoff curve would look like
>
>
> On 23/12/10 10:17 AM, Chris Pollach wrote:
>> Hi;
>>
>> What I normally do in this case is ...
>>
>> 1) Disable the Retrieve on the DC
>> 2) Hide the DC
>> 3) Add another DC from the System class beside the current one.
>> 4) Use the same DWO as in the real DC
>> 5) Use the SetRedraw ( ) to turn off visualization
>> 6) Run a Retrieve ( ) on the temporary DC to check its performance.
>>
>> If the test DC performs like the original one - look for problems in the
>> DB connection and SQL. If the test DC works like the DS - then go back
>> and analyze the original DC's scripts.
>>
>> HTH
>>
>> Regards ... Chris
>> President: OSUG / STD Inc.
>> Blog: http://chrispollach.blogspot.com
>> PBDJ: http://chrispollach.sys-con.com
>> SourceForge: http://sourceforge.net/projects/stdfndclass
>>
>> "300ZX" wrote in message news:4d12c535@forums-1-dub...
>>
>> I appreciate all your thoughts on this
>>
>> I had the idea of ds to sharedata already tucked away in my head when I
>> saw initially how quick the ds retrieved...however you and Jason may be
>> correct in that it is just caching, but of course i'm getting ahead of
>> myself as testing is far from complete.
>>
>> Not sure on the time from retrieve end to vis but that is another good
>> question. It's just a bad time of year to be doing remote tests with the
>> clients as most are on holidays but I'll keep you posted on what I
>> discover
>>
>> thanks again to all and merry christmas
>>
>> On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
>>> That probably takes buffering out of the situation.
>>> Try two successive retrieves to see if DBMS caching is a factor.
>>> I'd also try to find out if painting the DW is the factor - how long
>>> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
>>> painted until/unless you print it.
>>> How about retrieve into a DS and ShareData? That would require that the
>>> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
>>> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
>>> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
>>> them! In that case we retrieved the codes into a DS and shared it with
>>> the DataWindowChild for each DDDW, saving a lot of time.
>>>
>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>> Product Enhancement Requests:
>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>
>>> On 12/22/2010 8:07 PM, 300ZX wrote:
>>>> Understood but in my case I have nothing in the RR event...other common
>>>> events yes
>>>>
>>>>
>>>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>>>> Just for grins I added a comment to a DW's RetrieveRow script and
>>>>> looked
>>>>> at the source. It generated
>>>>>
>>>>> event retrieverow;// comment
>>>>> end event
>>>>>
>>>>> and I strongly suspect that the event declaration, which was not there
>>>>> before I added the comment, is what the DW engine is looking at.
>>>>>
>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>> Product Enhancement Requests:
>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>
>>>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>>>> I was under the assumption all comments(regardless of where they
>>>>>> reside)
>>>>>> were ignored at compile time and therefore were harmless....learn
>>>>>> something new everyday
>>>>>>
>>>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>> Speculation, but it's easy for code in the DW engine to tell that
>>>>>>> the
>>>>>>> script exists and less so to parse it to determine if it actually
>>>>>>> does
>>>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done
>>>>>>> and
>>>>>>> focus is set to the first row.
>>>>>>> I don't think other scripts would effect buffering - RetrieveRow
>>>>>>> fires
>>>>>>> after each row is retrieved so it requires each row to be fetched
>>>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>>>> requires several "handshaking" messages to pass across the network,
>>>>>>> hence the performance hit.
>>>>>>>
>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>> Product Enhancement Requests:
>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>
>>>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>>>> disables
>>>>>>>> buffering? Would that be true of other event such as
>>>>>>>> rowfocuschanged?
>>>>>>>>
>>>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>>> Some random thoughts...
>>>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment
>>>>>>>>> disables
>>>>>>>>> buffering.
>>>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>>>> display
>>>>>>>>> column is available for printing.
>>>>>>>>> Successive retrieves often perform better on the 2nd and following
>>>>>>>>> because of cached data on the server and other internal stuff that
>>>>>>>>> gets
>>>>>>>>> "warmed up".
>>>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>>>
>>>>>>>>> Report Bugs to Sybase:
>>>>>>>>> http://case-express.sybase.com/cx/welcome.do
>>>>>>>>> Product Enhancement Requests:
>>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>>
>>>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>>>> I've run into a problem that may be distinct to a particular
>>>>>>>>>> client
>>>>>>>>>> machine and/or network but it raised an interesting question
>>>>>>>>>> while
>>>>>>>>>> doing
>>>>>>>>>> a quick test......
>>>>>>>>>>
>>>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>>>> retrieve
>>>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>>>> unacceptable
>>>>>>>>>> for
>>>>>>>>>> any machine. As a quick test I created a ds with the same dwo and
>>>>>>>>>> same
>>>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>>>> sec).
>>>>>>>>>>
>>>>>>>>>> My question is even with setredraw false is there other
>>>>>>>>>> processing
>>>>>>>>>> going
>>>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>>>> would
>>>>>>>>>> trigger any external processes.
>>>>>>>>>>
>>>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>>>> may be
>>>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>>>> perhaps? I haven't had a chance to do comparative tests with
>>>>>>>>>> other
>>>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>>>
>>>>>>>>>> Can anyone shed some light on this?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>
>>>>>>
>>>>
>>
>

0
300ZX
12/25/2010 4:24:43 AM
I never thought about the functions but there are two in the footer, one 
displaying rowcount and the other summing column values


On 24/12/10 1:31 PM, Jerry Siegel [TeamSybase] wrote:
> If you have the key for the DDDW table and it is indexed (or the table
> is small) I would expect an improvement.
> Another thought: any grouping or cumulative functions used in computed
> fields? Especially with global function calls? That could cause some
> heavy crunching when the DW is painted.
>
> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
> Product Enhancement Requests:
> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>
> On 12/23/2010 7:20 PM, 300ZX wrote:
>> actually I am compiling a list of sequential tests to determine the
>> optimum approach and that is one of them
>>
>> another thought I had was to drop the dddw and opt for joins instead but
>> not sure what the tradeoff curve would look like
>>
>>
>> On 23/12/10 10:17 AM, Chris Pollach wrote:
>>> Hi;
>>>
>>> What I normally do in this case is ...
>>>
>>> 1) Disable the Retrieve on the DC
>>> 2) Hide the DC
>>> 3) Add another DC from the System class beside the current one.
>>> 4) Use the same DWO as in the real DC
>>> 5) Use the SetRedraw ( ) to turn off visualization
>>> 6) Run a Retrieve ( ) on the temporary DC to check its performance.
>>>
>>> If the test DC performs like the original one - look for problems in the
>>> DB connection and SQL. If the test DC works like the DS - then go back
>>> and analyze the original DC's scripts.
>>>
>>> HTH
>>>
>>> Regards ... Chris
>>> President: OSUG / STD Inc.
>>> Blog: http://chrispollach.blogspot.com
>>> PBDJ: http://chrispollach.sys-con.com
>>> SourceForge: http://sourceforge.net/projects/stdfndclass
>>>
>>> "300ZX" wrote in message news:4d12c535@forums-1-dub...
>>>
>>> I appreciate all your thoughts on this
>>>
>>> I had the idea of ds to sharedata already tucked away in my head when I
>>> saw initially how quick the ds retrieved...however you and Jason may be
>>> correct in that it is just caching, but of course i'm getting ahead of
>>> myself as testing is far from complete.
>>>
>>> Not sure on the time from retrieve end to vis but that is another good
>>> question. It's just a bad time of year to be doing remote tests with the
>>> clients as most are on holidays but I'll keep you posted on what I
>>> discover
>>>
>>> thanks again to all and merry christmas
>>>
>>> On 22/12/10 10:06 PM, Jerry Siegel [TeamSybase] wrote:
>>>> That probably takes buffering out of the situation.
>>>> Try two successive retrieves to see if DBMS caching is a factor.
>>>> I'd also try to find out if painting the DW is the factor - how long
>>>> between RetrieveEnd and visibility? I'm pretty sure a DS does not get
>>>> painted until/unless you print it.
>>>> How about retrieve into a DS and ShareData? That would require that the
>>>> DDDW be manually retrieved, it's not automatic as with a DW retrieve.
>>>> DDDW retrieves can be time-consuming. I recollect a DW that simulated a
>>>> Medicare form, and it had DDDWs for diagnosis codes - about 10,000 of
>>>> them! In that case we retrieved the codes into a DS and shared it with
>>>> the DataWindowChild for each DDDW, saving a lot of time.
>>>>
>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>> Product Enhancement Requests:
>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>
>>>> On 12/22/2010 8:07 PM, 300ZX wrote:
>>>>> Understood but in my case I have nothing in the RR event...other
>>>>> common
>>>>> events yes
>>>>>
>>>>>
>>>>> On 22/12/10 5:32 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>> Just for grins I added a comment to a DW's RetrieveRow script and
>>>>>> looked
>>>>>> at the source. It generated
>>>>>>
>>>>>> event retrieverow;// comment
>>>>>> end event
>>>>>>
>>>>>> and I strongly suspect that the event declaration, which was not
>>>>>> there
>>>>>> before I added the comment, is what the DW engine is looking at.
>>>>>>
>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>> Product Enhancement Requests:
>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>
>>>>>> On 12/22/2010 4:27 PM, 300ZX wrote:
>>>>>>> I was under the assumption all comments(regardless of where they
>>>>>>> reside)
>>>>>>> were ignored at compile time and therefore were harmless....learn
>>>>>>> something new everyday
>>>>>>>
>>>>>>> On 22/12/10 4:07 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>> Speculation, but it's easy for code in the DW engine to tell that
>>>>>>>> the
>>>>>>>> script exists and less so to parse it to determine if it actually
>>>>>>>> does
>>>>>>>> anything. RowFocusChanged wouldn't fire until the retrieve is done
>>>>>>>> and
>>>>>>>> focus is set to the first row.
>>>>>>>> I don't think other scripts would effect buffering - RetrieveRow
>>>>>>>> fires
>>>>>>>> after each row is retrieved so it requires each row to be fetched
>>>>>>>> individually rather that in a block. Each interaction with the DBMS
>>>>>>>> requires several "handshaking" messages to pass across the network,
>>>>>>>> hence the performance hit.
>>>>>>>>
>>>>>>>> Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
>>>>>>>> Product Enhancement Requests:
>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>
>>>>>>>> On 12/22/2010 12:48 PM, 300ZX wrote:
>>>>>>>>> nothing in the retrieverow, but can you explain why a comment
>>>>>>>>> disables
>>>>>>>>> buffering? Would that be true of other event such as
>>>>>>>>> rowfocuschanged?
>>>>>>>>>
>>>>>>>>> On 22/12/10 12:27 PM, Jerry Siegel [TeamSybase] wrote:
>>>>>>>>>> Some random thoughts...
>>>>>>>>>> Anything in the RetrieveRow event of the DW? Even a comment
>>>>>>>>>> disables
>>>>>>>>>> buffering.
>>>>>>>>>> I'm pretty sure DDDW would have to be retrieved in a DS, so the
>>>>>>>>>> display
>>>>>>>>>> column is available for printing.
>>>>>>>>>> Successive retrieves often perform better on the 2nd and
>>>>>>>>>> following
>>>>>>>>>> because of cached data on the server and other internal stuff
>>>>>>>>>> that
>>>>>>>>>> gets
>>>>>>>>>> "warmed up".
>>>>>>>>>> There was a total eclipse of the moon yesterday ;-)
>>>>>>>>>>
>>>>>>>>>> Report Bugs to Sybase:
>>>>>>>>>> http://case-express.sybase.com/cx/welcome.do
>>>>>>>>>> Product Enhancement Requests:
>>>>>>>>>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>>>>>>>>>
>>>>>>>>>> On 12/22/2010 12:08 PM, 300ZX wrote:
>>>>>>>>>>> I've run into a problem that may be distinct to a particular
>>>>>>>>>>> client
>>>>>>>>>>> machine and/or network but it raised an interesting question
>>>>>>>>>>> while
>>>>>>>>>>> doing
>>>>>>>>>>> a quick test......
>>>>>>>>>>>
>>>>>>>>>>> I do a retrieve on a datawindow with setredraw false and the
>>>>>>>>>>> retrieve
>>>>>>>>>>> time is horrible(8 minutes for 4500 records). Certainly
>>>>>>>>>>> unacceptable
>>>>>>>>>>> for
>>>>>>>>>>> any machine. As a quick test I created a ds with the same dwo
>>>>>>>>>>> and
>>>>>>>>>>> same
>>>>>>>>>>> arguments and the client said it retrieved quickly as expected(1
>>>>>>>>>>> sec).
>>>>>>>>>>>
>>>>>>>>>>> My question is even with setredraw false is there other
>>>>>>>>>>> processing
>>>>>>>>>>> going
>>>>>>>>>>> on inside a dw that does not on a ds? I have no dw events that
>>>>>>>>>>> would
>>>>>>>>>>> trigger any external processes.
>>>>>>>>>>>
>>>>>>>>>>> The dwo does have a few dddw's and my spidy sense tells me this
>>>>>>>>>>> may be
>>>>>>>>>>> the culprit even with redraw off. That the ds ignores the dddw's
>>>>>>>>>>> perhaps? I haven't had a chance to do comparative tests with
>>>>>>>>>>> other
>>>>>>>>>>> machines yet. I'm using 10.5.2 and MSS2005 with ODBC
>>>>>>>>>>>
>>>>>>>>>>> Can anyone shed some light on this?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>

0
300ZX
12/25/2010 4:29:42 AM
You should look at SQL Profiler and verify that for the DW that you are not 
generating "Server Side Cursor" operations.  That can cause a big 
performance hit, especially if the DB is not on the same machine or the DB 
does not have a very fast temp database store location.

"300ZX"  wrote in message news:4d1230aa@forums-1-dub...

I've run into a problem that may be distinct to a particular client
machine and/or network but it raised an interesting question while doing
a quick test......

I do a retrieve on a datawindow with setredraw false and the retrieve
time is horrible(8 minutes for 4500 records). Certainly unacceptable for
any machine. As a quick test I created a ds with the same dwo and same
arguments and the client said it retrieved quickly as expected(1 sec).

My question is even with setredraw false is there other processing going
on inside a dw that does not on a ds? I have no dw events that would
trigger any external processes.

The dwo does have a few dddw's and my spidy sense tells me this may be
the culprit even with redraw off. That the ds ignores the dddw's
perhaps?  I haven't had a chance to do comparative tests with other
machines yet. I'm using 10.5.2 and MSS2005 with ODBC

Can anyone shed some light on this?

Thanks 

0
Tyler
12/28/2010 4:12:06 PM
If the client runs your app with /PBDEBUG as a command line
argument, all actions will be traced and logged in a file.
You can then examine that file, and possibly see where the
problem is. I would expect one of two outcomes:
1. Huge log file, where some function or event is repeatedly
being called. Find out why, this is probably the cause of
the slowdown.
2. Relatively small log file, meaning PB is not working too
hard during the retrieve. This means the problem is on the
database side, and that's where you should further
investigate.

If possible, watch the log file as the log retrieve is being
executed. If it doesn't grow, you're probably facing the
second outcome. Also, bare in mind the log might get huge.
It can be effectively compressed, but it might also cause
your app to run much slower. You may kill it after a few
minutes, and still have all the info you need in the log.
0
Eran
12/29/2010 6:57:45 AM
Reply:

Similar Artilces:

DataWindow vs. DataStore #2
When we were first designing our PB app around 5-6 years ago, we hired a Sybase consultant to help us set everything up and get the ball rolling. He advised us to always use a dataSTORE to retrieve from and save to the database, and to create a dataWINDOW which is SHARED with this datastore to place on the window. The dataSTORE is primary and the dataWINDOW is secondary in the share relationship. So, all of our ancestor windows create a datastore, which is shared with a datawindow, whihc is located on the window. This structure is the backbone of our system. What would be the advan...

Datawindow vs datastore performance
This is a multi-part message in MIME format. ---=_forums-2-dub44c53fc3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I recently tried out a comparison of datawindow vs datastore performance (re-created from an article I came across: see attached code). Here is my result for inserting 1000 records: visible window and datawindow on it = 0.046 invisible window and datawindow on it = 0.078 visible window and invisible datawindow on it = 0.047 visible window and datawindow with no redraw on it = 0.047 datastore = 0.062 I would have thoug...

DataWindow This, DataWindow That...
Blah blah blah You've heard it enough that you don't even want to comment on how many times... The DataWindow. ....but it can't be enough anymore...can it? This from one of our colleagues (and yes my apologies for taking it out of context)... "...PB covers all you need to do that in ONE Tool. This includes Windowprogramming ( meaning the interface to the user: Windows, Sheets, diallougeboxes, etc.), Database operability AND Reporting! Well, I see als well as many other PB users that some of the implementations and features PB offers are improvable. But thi...

Is DataWindow 2.5 in Dw.Net is same as DataWindow in PB11.2
Hi there , Can anybody confirm the said subject is a valid statement ? Dw.Net2.5 = PB11.2.DataWindow ???? How about the future enhancements which are planned for PB11.5 and future releases of PB... Will it not always be in the same codestreamline ? Regards , Van I mean how will be co-relate the three products from Sybase 1) DataWindow.Net 2.5 for Visual Studio 2008 2) PocketPowerBuilder Datawindows 3) PowerBuilder11.2 and Powerbuilder1x.x Datawindows All everthing is remain the same in all the above three products as far as Datawindow properties / events /...

1 Xml -> 2 DataWindows; 2 DataWindows -> 1 Xml
Hi Is it possible to import an Xml file like <data> <dataX>...</dataX> <dataV>...</dataV> <dataV>...</dataV> <dataV>...</dataV> ... <dataV>...</dataV> </data> to one Datawindow ? On the other hand is it easily possible to assemble data from two Datawindows in one XML file ? thanks Thomas Kovasits Thomas Kovasits wrote: > Hi > Is it possible to import an Xml file like > <data> > <dataX>...</dataX> > <dataV>...</dataV> > &l...

Html-datawindow vs web-datawindow
Hi! We have mede some pages using datawindowbuilder. There we used html-datawindows. Now we have upgraded to PB8 and here it is called web-datawindow. What is the differense? 40% of the pages arnt working after we migrated to PB8. It seems like there have been some changes? Regards Staale What errors are you seeing with the problem pages? A. Staale wrote: > Hi! > > We have mede some pages using datawindowbuilder. > There we used html-datawindows. > Now we have upgraded to PB8 and here it is called web-datawindow. > What is the differense? >...

How can I count number of rows in each datawindow in composit datawindow then access and set item in each row in each datawindow! #2
This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C308EA.0E4861E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi friends, I created a composite datawindow includes three datawindow. How can I count the number of rows in each datawindow? (Rowcount() function can = not works). Also, I need access in each row then reset the value that I want = in each row in each datawindow. I use the property to access to get data in each row in each datawindow, but the right value only happens in the = fi...

DataStores vs DataWindows
I am currently developing a Client/Server application using PB 6.0. I started off using data windows on the client side but now I'm considering switching to datastores on the client side with datawindows on the server. I've heard this method is optimal for client/server applications since it saves space on the client and it decreases network traffic. However, it requires more coding. I would like to hear opinions on the pros and cons of this approach. Sam Not sure what you are doing. Is this a batch application? How are you going to display data to the user? A litt...

DataWindow vs. Datastore
When doing data conversions, my company has a standard of using DataWindows and reading the data row by row. The datawindow is set to invisible, no rows are added by the program, and the rows are processed forward-only. I was wondering what are the performance differences between DataWindows, DataStores, or even Cursors in a process like this? I'm not aware of any siginificant performance issues, although in theory there should be some little.. But if you have tons of invisible dws on a window it will blow up your memory. Datastores can be destroyed easily. HTH Thor...

PowerBuilder DataWindow #2
Hi all, I have a requirement to implement a master-detail sheet. That's ok. However, based on the user-logged-in credential, the user may OR may not be able to edit the details part. Now I can easily implement this by adding a constraint while updating the details' data. if user_can_edit then update end if The problem is this: If the user is not entitled to make changes, he is still able to put focus to the details' form data and modify (of course I am not updating it)...but the user can get a feeling "oh I am able to modify the data". Is it so...

datawindow performance #2
Hi I am using powerbuilder 6.5 and have used a lot of datawindows to perform retrievals, against microsoft sql server 7.0 I consultant recently mentioned that because our system did not use stored procedures but used direct datawindow retriveals (which he termed ad hoc retrievals) , our system would not be able to handle too many users. We have used lots of cached dddw which simplfy the queries and our queries generally use the primary index. Am I faced with huge problems ? Any help would be appreciated Tia Aryeh Aryeh, The question you should ask y...

Datawindow vs Datastore
I can create and destroy Datastores on the fly. Is it possible to do the same with datawindows? Scott, You can create and destroy DataStores at will, using the CREATE and DESTROY keywords, respectively. You cannot create visual objects using the CREATE command, so you cannot do this with DataWindows. However, you can create a DataWindow user object (or use u_dw, if you are using PFC) and use the OpenUserObject/CloseUserObject functions. HTH, Greg -- ______________________________ Gregory R. George Greg_George@AscensionLabs.com Ascension Labs, LLC www.AscensionLa...

datastore vs datawindow
Having a problem setting the transaction object for a datawindow... PB 8.03 In a non-visual I have the following code: datawindow ldw_a ldw_a = create datawindow ldw_a.dataobject = 'd_a' li_rc = ldw_a.settransobject( sqlca ) li_rc returns a -1 replaced it with: datastore lds_a lds_a = create datastore lds_a.dataobject = 'd_a' li_rc = lds_a.SetTransObject( sqlca ) li_rc returns a 1 Verified that the dataobject exists, is named correctly and is valid so why does SetTransObject work if I define it as a datastore, but not as a datawindow? Is there somet...

How to share the datawindow to inner datawindow of nested datawindow
How to share the datawindow to inner datawindow of nested datawindow. Ex -------- dw_1 is normal datawindow dw_nes is nested datawindow, both are placed one window dw_nes contain dw_child datawindow Question ---------------- i want to share dw_1 and dw_child. I have tried the below code, getting error dw_1.sharedata( dw_nes.object.dw_child) It's the dot notation. You will need to dw_nes.GetChild("dw_child", ldwc) where ldwc is a _local_ datawindowchild. <kzganesan@gmail.com> wrote in message news:4c64c402-bac5-4ee0-83aa-4ac08ffe43e5@r66g2000hsg.go...