I have a form with multiple tabs with variable list views. I have them initially load the tabs not initially displayed with where clause “WHERE limit = 1”. Then on tab change eep I load the data for that tab.
The user cannot see the other tabs until the click on them so that data is not needed until then. It is much faster than trying to load them all at once. My on tab change eep: SET VAR vewhere TEXT GETPROPERTY variablelookuplistview1 lookupwhereclause 'vewhere' IF vewhere CONTAINS 'limit' THEN PROPERTY variablelookuplistview1 lookupwhereclause + 'WHERE modyear = .vmodyear and pvpnid not in (select pvplpartid from pvpl) ORDER BY pvpnpartnumber ASC' PROPERTY variablelookuplistview1 REFRESHLIST 'TRUE' ENDIF CLEAR VAR vetab RETURN Load on Demand works for me. Dan Goldberg From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Tuesday, January 13, 2015 12:43 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Form startup speed / network I suspect it is those 12 data pulls that are taking the time, always slower with multiple users on the db. You might want to figure out a way to only pull the first tab, and pull the data on the other tabs as there selected. Try a copy of the form with all the listviews removed except the one on the first tab. This should give you some blues clues. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, January 13, 2015 2:25 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Form startup speed / network A general question that I happened to run into this week end. Saturday night I was working on the system and installed new updates. (A rare time when everyone was off the network.) I ran a complex form that was previously relatively slow in calling up and was very pleased to see the starting speed increase from 35+ seconds to about 5. However, now back during the work day, the form is pretty much back to it's old starting speed. The form runs fine once started, it is just the start up speed that is in question here. I have eliminated just about all variables except two: 1) The Windows server software 2) Something in how I have Rbase setup or how this particular form works on a network Details: 9.5 latest updates Gig network (cards and switches etc.) Dedicated file server Network runs fine, no issues with speed (except this form start up) Compiled EXE's are all located on the local machine, database on the file server. Using different computers, terminal server sessions, compiled versus full Rbase and many different tests eliminating hardware and network issues, the following is found. Start the form with only 1 or 2 other computers connected to the database (all standing idle), the form calls up in 5 seconds. Start the form with 30 computers / terminal server sessions connected to the database via complied app (all standing idle however), the form takes 35 + seconds to start. Make a copy of the database on the same drive and folder as the live database. 30 computers / terminal server sessions still on the network, connected to the live database. Form calls up in the copy database in 6 seconds. So the additional users on the network itself is not the problem. Only when there are several users connected to the database. Once the form is fully started, it runs fine. It just takes a long time to start when several users are connected to the database, even when all the others are sitting idle, performing no function, just sitting there connected to the database. I have performance monitors running on the server and during all tests, the results are the same. There is very little server CPU activity,< 2% and almost no network activity < 1%. This is a new form and is somewhat complex. It has an enhanced Tab control with 12 tab pages. Each tab has a variable lookup list view. So the question is why 5 seconds to start with few users connected and 6 times as long when several users (sitting idle) are connected? Why would only the startup speed be affected? Thoughts anyone? Thanks, Bob
