bb.donnay-software.com

Roger,

I worked around it, but have a question regarding refreshing dc_browse when making major changes in what detail shows.

Creating using a selection on the database: This method is used due to size of database and future filters they will select
x1=0
aRecpro1 := {}
DO WHILE oppro->opstatus == "A" .and. .not. eof()
AAdd(aRecpro1,oppro->(RecNo()))
x1=x1+1
SKIP
ENDDO
if x1=0
AAdd(aRecpro1,oppro->(Reccount()+1))
endif
DC_SetScopeArray(aRecpro1)
DC_DbGoTop()

@ 1,0 DCBROWSE oBrowse ALIAS 'Oppro' ;
NOSIZECOLS PRESENTATION APRES CURSORMODE XBPBRW_CURSOR_ROW ;
SIZE nnn,18 ;
FIT


We have a button to select a filter which is done in a child window. so then it skip records it does not want. Example

x1=0
aRecpro1 := {}
DO WHILE oppro->opstatus == "A" .and. .not. eof()
if !empty(vddiv) .and. opdivtype<>vddiv
skip
loop
endif

AAdd(aRecpro1,oppro->(RecNo()))
x1=x1+1
SKIP
ENDDO

Sends the filter selection and getlist, then refreshes.

The process takes a second or less, even with a high volume of records.

The browse sits there for 15-30 seconds before it refreshes.

I finally exited when the button was selected (closed the browse) to let the user select the filter after the exit), and then it refreshed immediately set in a loop.

I thought there was a refresh on the browse that would do that, but could not find any that did. The obrowse:refreshall() said it was invalid(?) when I tried that when returning from the child window. Found that in your samples and copies/pasted it in, no idea why it was not valid.

Just curious for next time..

Thanks
Fred
Omni

Maybe selecting the hits doesn't take that much time, but if you skip thousands and thousands of (following) records that don't match, it may take 15 to 20 seconds to do this. What I'm trying to tell you: Set several measure points and try to find out what exactly takes so much time. It's not the browse. It's your searching routine.
Besides, if you (heavily) change an array which is the datasource of a browse, re-connect it to the browse using DC_GetBrowArray(oBrowse,aMyArray). Do a "RefreshAll()" afterwards, maybe add a "ForceStable()".

Yes, I added an alert after the array was rebuilt, still only took less than a second. The only thing after that was the refreshing and returning to the browse. I had tried the forcestable and it did not help.

Not a big deal since I got it to work. Just seeing if I missed something basic.

Fred

Hi,

I was wondering if you do a new DC_SetScopeArray(aRecpro1)?

Yes, it can take a good amount of time to build a scope array if the data set is large, with filtered or many deleted records.

This is why I have been advising customers who already are using ADS to use a SQL query instead in those situations. This always is much faster.

Hi Roger,

I think that dc_setscopearray is much powerfull than you think. It is amazingly fast, even on large datasets.

Creating the array can take time, but once the scope is set, there isn't any delay when scrolling.

I'm using it as a multi dimensional array, where the 2-thd element is a placeholder to sort. This way I can fill it with the column I want to sort, do an asort() on the array, and my browse is sorted on the column. This is working great and super fast.

Yes, I love DC_SetScopeArray(). Too bad it isn't supported by dbSkip(). It requires DC_DbSkip().

Once the array is loaded then there isn't anything faster for browsing.