Individual vs.whole dB locks on forms/reports during modification

  • Thread starter Thread starter Guest
  • Start date Start date
Albert,

I've used a hidden form with persistent connections on a few front ends and
at least once it caused a memory leak and shot CPU usage to 100%. Other
times it works just fine, and it does speed them up when it works. I agree.

Our company is still languishing with some cat5 at 10Mbps while some are at
100Mbps. I can live with the speed at 100, but my co-workers at 10Mbps get
bogged down big time. Just to run a union query that draws data from two
other queries takes well over twice as long on the slower connections. We've
done the comparisions.

I'm thinking SQL server is the next step, to help reduce network traffic
dependence. But that's no small change.

Mike
 
Let's see if we can get past the frustration and the personal friction and
deal with the technical issues, shall we?

To the best of my knowledge, neither Roger nor Klatuu work for Microsoft. I
certainly do not work for Microsoft. So there is no reason to expect any of
us to know the reasoning behind any of Microsoft's design decisions.

For whatever it may be worth, I believe I recall a post from Michael Kaplan
(a person who is extremely knowledgeable about Access) some years ago,
probably in the comp.databases.msaccess newsgroup, in which he indicated
that the change was necessary because design changes without exclusive
access could cause corruption. This is, as I say, just my memory of
something someone else has written, so please don't quote me on that.

The solution is to split the 'front-end', application MDB from the
'back-end' data MDB, so that you always make design changes to a local copy
of the application MDB, which you can then copy to the users' PCs without
overwriting the data in the data MDB. I gather from your other recent post
in this thread that you may be having some issues with this approach. (Some
of the earlier posts in this thread are no longer visible to me, so I do not
have the full picture at this stage.) If so, those issues can almost
certainly be resolved - this approach works well for many people, it can
almost certainly be made to work well for you. I suggest waiting a day or
two to see if this thread may lead to a resolution of that problem, and if
it does not starting a new thread on that issue.
 
mikebris@bmcd said:
Albert,

I've used a hidden form with persistent connections on a few front ends
and
at least once it caused a memory leak and shot CPU usage to 100%. Other
times it works just fine, and it does speed them up when it works. I
agree.
Click to expand...

Hum, I never seen the above problem (memory leak, or 100% cpu being "due"
to the above). So, the above seems to be a VERY isolated case here.

To be fair, I personally use a global reocrdset to keep the connection
open. However, I not seen ANY posts complaining that this causes a memory
leak, and/or a 100% cpu problem. I just have not seen this.

Do note that the CPU issue jumping to 100%, that was a COMMON problem
in a97, but this was not related "invisible" form, and this problem was
fixed
in later versions. So, I seen nothing in the way of newsgroup posts
to suggest the CPU issue being related to a persistent connection.

I would suggest that you distribute a mde to each station. And, just in case
there
is any diffiltiy in the IT deparmet as to "why" you split, you can read the
follwoing:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

I like the above article very much, as I explay "why" you split, not just
tell you
that you "should".

Give the above the read, as it also explaines why stablity improves so much
when you do split (and, it also explains why you should use a mde).
Our company is still languishing with some cat5 at 10Mbps while some are
at
100Mbps. I can live with the speed at 100, but my co-workers at 10Mbps
get
bogged down big time. Just to run a union query that draws data from two
other queries takes well over twice as long on the slower connections.
We've
done the comparisions.
Click to expand...

Interesting, but you are talking about a connection that is 10 times slower.
So, only suffering a loss 1/2 is not bad....

You can actually make application work on a much less bandwidth then a
"10-t", and I explain some solutions here:

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
 
Back
Top