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

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

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 

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

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

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

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

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
>

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
>>

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
>>>
>

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
>>>
>

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
>>>
> 

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
>>>>
>>

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
>>>>>
>>>
>

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
>>>>>>
>>>>
>>

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
>>>>>>
>>>>
>> 

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
>>>>>>>
>>>>>
>>>
>

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
>>>>>>>
>>>>>
>>>
> 

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
>>>>>>>>
>>>>>>
>>>>
>>
>

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
>>>>>>>>
>>>>>>
>>>>
>>
>

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
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>

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 

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.