Re: Slow Accessing a memo field on a network

No problem there - I have read it into a variable and it is much faster.
I'm just making the obeservation that it is equally fast when the size of
the memo field is 500 bytes or less. I'm thinking VFP might be buffering
records of 500 bytes or less which could explain the speed difference in a
shared environment. Either way, I agree that it's best practice to read it
into a variable.

Thanks,
Mike

"Cy Welch" <cywelch@xxxxxxxxxxx> wrote in message
news:64D108C9-C258-40F6-8E36-AA5931D2B98F@xxxxxxxxxxxxxxxx
As has been said multiple times, that is how it works. Any and all access
to table data in shared mode must be done by flushing the OS buffers and
reading the file EVERY time you read it, while in non-shared mode it's
read into memory and accessed from there (actually pretty much just like
it does if you read it into a memory variable and access it from there).
That is the way that file based databases MUST work to be even somewhat
reliable. In shared mode it can NEVER be assumed that what you read 10ms
ago is still the same. That's why not only for speed, but if you don't
want to have any chance of the data changing from one read to the next,
you MUST read it into a variable and access it from there.

--
Cy Welch
Senior Programmer/Analyst
MetSYS Inc.
http://www.metsysinc.com

"MikeA" <appell@xxxxxxxxxxxxxxxxxx> wrote in message
news:KnxIi.5866$oc2.3110@xxxxxxxxxxx
Let me add that granted I can get around this by simply reading the
memofield into a local variable one time and then process the information
from the local variable in the form and everything is quick. I agree
that that is proper coding technique. However, I'm not understanding why
with multiple reads from the same field (reading the memofield about 150
times) it's very quick but the moment the length of the field is over
500, the speed declines drastically.

Is this a network or maybe a VFP issue where in a shared file it
internally buffers up to 500 characters and if more, then rereads the
data and maybe that is why things slow down?

Thanks,
Mike

"MikeA" <appell@xxxxxxxxxxxxxxxxxx> wrote in message
news:IkxIi.5865$oc2.4559@xxxxxxxxxxx
I have just done some more research and this is really perplexing to me.

Here's what I found out. I played around with my memo field and I
noticed that regardless of the number of lines in the memofield the
slowness is due to the length of the memo field. The slowness (as per
my prior posts) only occurs when the file is opened for shared use. It
takes less than one second to open the form if the memo field is 500
characters or less. Once the memo field is more than 500 characters it
takes a whopping 11 seconds to open the form (but only when it is opened
for shared use).

What's that all about? Why is that happening? I have determined this
has nothing to do with my code and appears to be strictly a function of
the length of the memo field. Is that possible? Does anyone have any
ideas as to why this could be?

Thanks,
Mike


"Cy Welch" <cywelch@xxxxxxxxxxx> wrote in message
news:E2EEC760-EE82-4B52-B2AF-2D7E9664714E@xxxxxxxxxxxxxxxx
As you have been told that is normal behavior. When the table is open
by more than one computer VFP MUST check the record on disk each time
you access any field. If it's only open on one computer, it pulls it
into memory and doesn't look back at disk. It's pretty normal for
database access across the network to take as much as 10 times longer
under multiuser. Part of best practices over a network is to not do
more reads across the network than needed. In other words, always read
everything into memory and then read from memory unless you expect the
values to be changed. If everything only reads from the table you might
be able to get pretty much the same increase in speed if you open the
table read-only as it doesn't have to worry about locking in that
situation which is what slows access down.

--
Cy Welch
Senior Programmer/Analyst
MetSYS Inc.
http://www.metsysinc.com

"MikeA" <appell@xxxxxxxxxxxxxxxxxx> wrote in message
news:dEdIi.17429$re2.14254@xxxxxxxxxxx
I still have a feeling something else is going on here. I'll check
because I have another client that has an XP PRO they are using (for
the file server). I don't think their network has this problem but I'm
going to go over there today to double check this. I just can't see
being able to open a form in under one second and then if I have that
same table open on a second workstation that it could then take some
5-10 seconds to open that same form. The table is only one record and
the dbf is 11K and the fpt is 15K. The only good news is that I hae
simulated the same problem here on my network as well.

Mike


"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:%23Ec71Uu%23HHA.2004@xxxxxxxxxxxxxxxxxxxxxxx
ALL data access is slower when multiple users are involved. It *has*
to be.

VFP cannot rely on its local cache. It must first ask Windows to poll
the network to see if other users have cached changes that must be
updated to the server and then updated to the local cache.

It's the nature of the beast. Some networks will handle it better
than others. In your OP you mentioned a "Windows XP server" --
Windows XP is not a server operating system. I'd expect it to be the
least capable "server" of the lot because it isn't one. ;-)

Dan

MikeA wrote:
Thank you all for your replies but I think you may be missing what
I'm
asking. I understand that the memofield access can be slow
especially if the memofiled is large. However, my memofield is no
more than 3K but does contain around 150 lines. My question is why
is it so much slower when the file is open at another workstation on
the network, otherwise, it is very fast to loop through the
memofield.

My question is whether it is normal for the memofield access to be
very fast when accessing it over a network on workstation #1. But,
very slow if the table is open at another workstation on the
network?
I noticed that it is definitely a lot faster when I simply copy the
memofield to a variable and then access the lines via the local
variable.
So, say I have 3 computers (one is the file server). I open the
table and it is slow to do multiple accesses of the memofield but
only if it is open on another computer. My fear is that all data
access may be slowing down but not enough to detect with the eye and
that maybe there is something else I'm not noticing. I have not
used
Set Refresh so that is just using the default and I am opening the
table via pessimistic locking but nothing is not locked on the
reads.
It's just the multiple accessing via the memofields when the table
is
open at another workstation that slows everything down. Also, I
don't think this is happening on all LANs and may depend on the
server and network setup. But, it does appear to be happening on
some so it really has me curious.
Thanks,
Mike


"Alex.K" <nomail@xxxxxxxxxx> wrote in message
news:%23k5ccbt%23HHA.1184@xxxxxxxxxxxxxxxxxxxxxxx
Mike,

You should only read the Memo field once and store it to a string
var. Then do all processing on the string. You can also use _MLINE
and MLINE() on strings.

Another method is to use ALINES() and process as an Array



- Craig

"MikeA" <appell@xxxxxxxxxxxxxxxxxx> wrote in message
news:JA5Ii.7361$A72.1856@xxxxxxxxxxx
Anyone have any ideas about this: here's the situation,

I have a memo field that I use in a table and I read various lines
from the memo field for default settings. This makes it so that I
don't always have to modify the structure of the table. The total
length of the memofield is small (under 3K). However, I have to
read the memo field multiple times to get the default values on
any
particular line. For example:

set memowidth to 8192
test1 = mline(mytable.mysettings, 1)
test2 = memline(mytable.mysettings, 2)
test3 = memline(mytable.mysettings, 3)
test4 = memline(mytable.mysettings, 4)

There are about 150 lines at present in the field. Here's the
strange thing. I have a method in a form that reads all the
values
and sets the objects on the form accordingly. It seems like it is
starting to take a long time to load the form (around 6-10
seconds). But, this delay is ONLY PRESENT if the table is open on
another computer on the network. If I open the table on the same
computer in a separate program (such as VFP) or I run another
instance of my application, then everything is fast. The slowness
only happens if the table is open on another workstation and it
appears that it is just as slow if the table is open on 2
workstations or 10 (makes no difference). It drastically speeds
up
when the table is open on only one workstation and is fast even if
that table is open on one computer with multiple programs (such as
if it is open in my app as well as open in VFP). I have noticed
this problem on both an XP Pro computer (as the
server) with XP workstations and I have also noticed this problem
on a real Win 2000 server with XP workstations. I'm using VFP
6/SP3. The problem only seems to happen when doing multiple reads
from the same memofield many times. In other words, if I do this
instead: m.lcMain = mytable.mysettings

and I then populate the form using m.lcMain then everything is
very
fast. It's as if multiple reads to the same memofield is really
slow but only if the table is open on another workstation. There
are no virus checkers or other programs (that I know of) to slow
it
down). I can't understand why this is happening but I'm not sure
if it is happening on other server OS's as well or just these few
examples I have provided. I'm running the exe on the local
machine. But, it seems to be some kind of network issue because
the speed drastically slows down (reading the memo field multiple
times) whether the table is open on two workstations or 10. It's
then pretty much the same slow speed when open at 2 computers or
more but lightening fast when open at only one. Anyone have any
ideas? Thanks,
Mike










.

Relevant Pages

  • Re: Slow Accessing a memo field on a network
    ... However, I'm not understanding why with multiple reads from the same field (reading the memofield about 150 times) it's very quick but the moment the length of the field is over 500, the speed declines drastically. ... Is this a network or maybe a VFP issue where in a shared file it internally buffers up to 500 characters and if more, then rereads the data and maybe that is why things slow down? ... I played around with my memo field and I noticed that regardless of the number of lines in the memofield the slowness is due to the length of the memo field. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Slow Accessing a memo field on a network
    ... I played around with my memo field and I noticed ... Part of best practices over a network is to not do more reads ... on a second workstation that it could then take some 5-10 seconds to open ... I understand that the memofield access can be slow ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Slow Accessing a memo field on a network
    ... It's pretty normal for database access across the network to take as much as 10 times longer under multiuser. ... I just can't see being able to open a form in under one second and then if I have that same table open on a second workstation that it could then take some 5-10 seconds to open that same form. ... It must first ask Windows to poll the network to see if other users have cached changes that must be updated to the server and then updated to the local cache. ... I understand that the memofield access can be slow ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Slow Accessing a memo field on a network
    ... Part of best practices over a network is to not do more reads ... on a second workstation that it could then take some 5-10 seconds to open ... I understand that the memofield access can be slow ... It drastically speeds up ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Slow Accessing a memo field on a network
    ... I don't think their network has this problem but I'm going to go ... the server and then updated to the local cache. ... I understand that the memofield access can be slow ... is it so much slower when the file is open at another workstation on ...
    (microsoft.public.fox.programmer.exchange)