Applications object - Local v/s Server

  • Thread starter Thread starter GeorgeMar
  • Start date Start date
G

GeorgeMar

I have an application that is split into front-end/ back-
end. It works well except that it slows down when the
number of concurrent users get above 10 users.

I have read the articles on what to look out for to reduce
network traffic and they have been implemented.

The only thing that I think may be an issue is the fact
that I have the font-end and the back-end on the same
server and all the users access the application from an
icon on their desktop.

I have read that it is better to have the application
objects on the local drive. However, in doing so, it will
mean that every time I have new version , I will have to
upgrade each workstaion. That is why I have the
application on the server.

1. Is it necessary to run the application locally and the
back-end on the server? Will the performance improve if
the application is running locally?

2. What is the best way to handle upgrades to the
application if the application is stored locally?

many thanks
george
 
George

Tony Toews has a free auto updating utility that may be of some use to you

http://www.granite.ab.ca/access/autofe.ht

Another alternative (which I have implemented as getting approval for things such as the updater is akin to finding little green men on Mars) is creating a Windows Scripting File that does the copying for you. I'll post the code below, and let you know that I have the actual FE hidden on the shared drive lest anyone feel the need to access it there - instead if they run the scripting file it will do as it is supposed to and copy the file for me! Please note that this does require that the user input their network login (the only thing I wasn't able to figure out how to get the first time around, but I may revisit...

Anyway, hope this helps
Jak

Code

On Error Resume Nex

Dim
Dim ob
Dim fs
Dim strMDEPat
Dim strMDENam
Dim strLocalPathFron
Dim strLocalPathBac
Dim strUserNam

strMDEPath = "K:\FilePath\
strMDEName = "Database.mde

strLocalPathFront = "C:\Documents and Settings\
strLocalPathBack = "\Desktop\
strUserName = InputBox("Please confirm your Windows Login" & Chr(13) & "i.e. jsmith", "Confirm Login!"

Set fso = CreateObject("Scripting.FileSystemObject"
Set f = fso.GetFile(strMDEPath & strMDEName

f.Copy strLocalPathFront & strUserName & strLocalPathBack, Tru

If Err <> 0 Then
WScript.Echo "The Windows Login you have provided in does not match the user logged in to this computer." & Chr(13) & "The program will now exit.
Err.Clea
Els
Set obj = GetObject(strLocalPathFront & strUserName & strLocalPathBack & strMDEName
obj.Visible = Tru
End I

Set f = Nothin
Set fso = Nothin
Set obj = Nothin

----- GeorgeMar wrote: ----

I have an application that is split into front-end/ back
end. It works well except that it slows down when the
number of concurrent users get above 10 users

I have read the articles on what to look out for to reduce
network traffic and they have been implemented

The only thing that I think may be an issue is the fact
that I have the font-end and the back-end on the same
server and all the users access the application from an
icon on their desktop

I have read that it is better to have the application
objects on the local drive. However, in doing so, it will
mean that every time I have new version , I will have to
upgrade each workstaion. That is why I have the
application on the server

1. Is it necessary to run the application locally and the
back-end on the server? Will the performance improve if
the application is running locally?

2. What is the best way to handle upgrades to the
application if the application is stored locally

many thank
georg
 
Thank you Jake.

I will try your suggestion.

Can you tell me if there will be a significant improvement
by having the application running locally?

regards
george
-----Original Message-----
George,

Tony Toews has a free auto updating utility that may be of some use to you:

http://www.granite.ab.ca/access/autofe.htm

Another alternative (which I have implemented as getting
Click to expand...
approval for things such as the updater is akin to finding
little green men on Mars) is creating a Windows Scripting
File that does the copying for you. I'll post the code
below, and let you know that I have the actual FE hidden
on the shared drive lest anyone feel the need to access it
there - instead if they run the scripting file it will do
as it is supposed to and copy the file for me! Please
note that this does require that the user input their
network login (the only thing I wasn't able to figure out
how to get the first time around, but I may revisit...)
Anyway, hope this helps!
Jake

Code:

On Error Resume Next

Dim f
Dim obj
Dim fso
Dim strMDEPath
Dim strMDEName
Dim strLocalPathFront
Dim strLocalPathBack
Dim strUserName

strMDEPath = "K:\FilePath\"
strMDEName = "Database.mde"

strLocalPathFront = "C:\Documents and Settings\"
strLocalPathBack = "\Desktop\"
strUserName = InputBox("Please confirm your Windows
Click to expand...
Login" & Chr(13) & "i.e. jsmith", "Confirm Login!")
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFile(strMDEPath & strMDEName)

f.Copy strLocalPathFront & strUserName & strLocalPathBack, True

If Err <> 0 Then
WScript.Echo "The Windows Login you have provided
Click to expand...
in does not match the user logged in to this computer." &
Chr(13) & "The program will now exit."
Err.Clear
Else
Set obj = GetObject(strLocalPathFront &
Click to expand...
strUserName & strLocalPathBack & strMDEName)
 
Can you tell me if there will be
a significant improvement
by having the application
running locally?
Click to expand...

You significantly increase the probability of corruption if you have
multiple users logged in to the same copy of the front-end or to a
monolithic database. I'd have to say that reduced chance of corruption would
qualify as a significant improvement.

But, from a performance / response perspective, not having to fetch all the
query, form, and report objects as well as associated macros and code across
a LAN will also be a significant improvement. I'd have thought that
intuitive.

And, as to "distributing" a new front end. I kept a "version number" in a
local table in the front-end, and a "version number" in the back end. If the
version number in a user's front end was older than the version number in
the back end, I'd show a message box informing them to download a new copy
of the front end file. And, although many of our users were not "computer
whizzes", none ever had a problem dragging and dropping a copy of the file
from the server folder to a folder on their local machine. This is discussed
in more detail at http://accdevel.tripod.com/versioning.htm.

Larry Linson
Microsoft Access MVP
 
Thank you very much all. It has been most helpful.

The reason for my apprehension was that I thought that
when a user loads the application that all of the
application is loaded into the local memory at once,
including all forms, queries etc..

regards
george
 
Back
Top