Subject: | Re: Code running Slow
| Date: | Mon, 22 Oct 2018 08:36:24 -0400
| From: | "Kevin Baker" <shcsbaker@gmail.com>
| Newsgroups: | pnews.paradox-programming
|
Steven-
I'm 99% sure. Each of our customer has their own folder with a copy of the
application in each folder, we have a few customer who have 2 or more
accounts (to access the same folder and data) and I bet maybe 2 or 3 of them
would "try" being on the same form at the same time. The preformance
increase for the rest of our customers is just too great to remove the
SetBatchOn() / Off(). Would like to hear your thoughts on the postrecord.
Mark-
I tried removing the SetBatchOn() and just using the DelayScreenUpdates, but
that took me back to 45-50 secs to open the form. Nearly 100% of my
customer are not advanced users so the set ranges or filters shouldn't be a
problem.
"Kevin Baker" wrote in message news:5bcadbbb$1@pnews.thedbcommunity.com...
Hi Everyone,
I've got a Checkbook style form and when I open the form, I run a custom
procedure to recalc the balances. When I have local share turn OFF, the
form opens in 3-4 secs (the db has around 20,000 records), when I turn local
share to ON, the form then takes 45-50 secs to open.
Here's the code on the ReCalc. CHECKS is the name of the tableframe, which
I set a GenFilter on before running the below code. The GenFilter uses the
last bank opened. Any ideals of why changing the local share causes such a
big change.
Thanks,
Kevin
Proc ReCalc()
var
tc,tc1 tcursor
tf uiobject
endvar
tc.attach(CHECKS)
tf.attach(CHECKS)
tf.action(dataunlockrecord)
if tf.atFirst() and tf.CkIDNum.isBlank() then
return
endif
if tc.atFirst()then
movetorecord(tc)
cp=tf.Payment
cd=tf.Deposit
tc.balances=0+cd-cp
while not tc.atLast()
pb=tc.balances
tc.nextRecord()
cp=tc.payment
cd=tc.deposit
tc.balances=(pb)-(cp)+(cd)
endwhile
else
if not tc.atFirst() then
tc.priorRecord()
while not tc.atLast()
pb=tc.balances
tc.nextRecord()
cp=tc.payment
cd=tc.deposit
tc.balances=(pb)-(cp)+(cd)
endwhile
endif
endif
endProc
|