Re: MDB File growing in size

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Stephen Haley (sjhng_at_btinternet.com.nospam)
Date: 02/10/05 

Date: Thu, 10 Feb 2005 21:24:57 -0000

You dont say how big the backend is. I had a 97 db running on the network in
similar circumstances that was very large, back end was split into 4 to get
arround size limitations. We had a very large drop in performance (10x) for
large updating routines which continued despite moving it and the processing
box onto a seperate 100mb switch. Eventually we simply moved the thing onto
its own server and ran the updates directly on the server as opposed to a
workstation. I suspect that Access does a lot of chatter to lock records etc
and a lot of caching goes on by the jet driver on the PC which is fine for
query work but hopeless for updates.
rgds
Stephen

"Immanuel Sibero" <goahead@getlost.com> wrote in message
news:uy2SiG7DFHA.3368@TK2MSFTNGP10.phx.gbl...
>
> Jim,
>
> You didnt say if the nonconsistent results (reliability issue) occurs when
> you run it locally.
>
> As I was reading your response, midway through it, I was thinking
> "network".
> Network cables, cards, hubs, switches. Then I could see that you were
> getting to the same conclusion. When you run locally and the results are
> solid, faster, and consistent 100% of the time and less than 100% off of
> the
> network, then the network infrastructure will be my next scrutiny. Check
> for
> flaky connections, i.e network cards, hubs, switches... anything between
> your workstation and the server.
>
> You should also still look over Tony's website, if you havent already.
>
> Immanuel Sibero
>
>
>
> "Jim" <Jim@discussions.microsoft.com> wrote in message
> news:B90025E1-F143-4ACB-9564-CB5DC3684E85@microsoft.com...
>> Thanks Ken and Immanuel, It's good to know that the size change is normal
> so
>> I can quit worrying about it. Our company collects data from our clients
> and
>> a process was written that creates an ODBC connection to our clients
>> data,
>> the data is imported to Access and a lot of back end processing is done
>> to
>> integrate their data into the existing database. That's where the speed
> and
>> reliability issues come in. If I run a process that takes 1 to three
> minutes
>> in a confined environment where the BE and FE are both local, that same
>> process can take 10 minutes or longer when the BE is on a network drive.
> We
>> also have several instances where all the data does not get imported.
> While
>> the process is slow every time we run it, the reliability issue is not
>> consistent at all. Running it twice on the same machine right in row can
>> yield different results. I'm starting to wonder if this is more of a
> network
>> problem within the company and has less to do with Access. I will
>> explore
>> that avenue. Thanks again to you both for your responses.
>>
>> "Ken Snell [MVP]" wrote:
>>
>> > An ACCESS database of 6 MB size is pretty small for ACCESS. The size
> change
>> > that you note is very normal when data are manipulated in the backend.
>> >
>> > This size change most likely has no relationship at all to the "speed
> and
>> > reliability problems" (whatever they are?) that you are referencing.
>> >
>> > If you can give us more info about the "speed and reliability
>> > problems",
>> > perhaps we can provide some ideas.
>> >
>> > --
>> >
>> > Ken Snell
>> > <MS ACCESS MVP>
>> >
>> >
>> > "Jim" <Jim@discussions.microsoft.com> wrote in message
>> > news:91329ABC-8C15-46B6-A123-6DF66FC47392@microsoft.com...
>> > > My application is now split into two pieces. Roughly a dozen users
> access
>> > > a
>> > > copy of the front end db on thier own desktops while the back end db
> sits
>> > > on
>> > > a network drive. We continue to have a series of speed and
> reliability
>> > > problems and being new to Access programming, I'm trying to get a
> grasp on
>> > > what I am seeing. I performed a simple test on my workstation. I
>> > > ran
> the
>> > > compact db utility on my front end database and checked the file
>> > > size.
> It
>> > > was 5.97 MB. Then I opened the db and ran one simple report which
> exports
>> > > some data to Excel. When I closed and checked the size again, I
>> > > found
> the
>> > > front end db had grown to 6.02 MB. I am wondering if this is normal
>> > > behavior
>> > > in Access. I'm also wondering if what ever is causing this issue
> could
>> > > also
>> > > be causing our speed and reliability issues. I would greatly
> appreciate
>> > > any
>> > > insight that anyone might have. Thanks in advance!!!!
>> >
>> >
>> >
>
>

Relevant Pages

  • RE: [fw-wiz] IPv6 comes in the game
    ... Microsoft Windows 2000/2003 server does 802.1x auth fine. ... wireless access as well as port access on certain switches in the network. ... then you're able to log the authentication at the RADIUS ...
    (Firewall-Wizards)
  • Re: Large network question
    ... I will have to use gigabit swtiches between main floor switches, ... Feasibility - It is very important that any kind of network is built, ... What kind of computers, what network interfaces do they have, what operating ... WWW server and DNS server at least. ...
    (comp.dcom.lans.ethernet)
  • Re: Large network question
    ... I will have to use gigabit swtiches between main floor switches, ... Feasibility - It is very important that any kind of network is built, ... computers can impose to the network. ... WWW server and DNS server at least. ...
    (comp.dcom.lans.ethernet)
  • Re: Network bottle neck, ow to investigate CSocket.
    ... > How can I test the network traffic between the server and the clients. ... Run Switches instead of hubs. ... You should be running it with SQL Server or at least the ...
    (microsoft.public.windows.server.networking)
  • Network Design Ideas
    ... have around fifty computers connected to a switches and a network dialup ... Connect the inside of this router to there network switches. ... Place a new web server into the DMZ. ... The clients also submit data to the sql database to identify ...
    (microsoft.public.windows.server.networking)