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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |
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 |
![]() |