|
Home > Archive > MS Access Multiuser > May 2005 > MSACCESS.EXE process on server?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
MSACCESS.EXE process on server?
|
|
|
| (access 2002)
multi user database with seperate front end mdb file on client machines.
Data in SQL 2000 Server. However the access workgroup file is located
centrally on the sql 2000 server computer (windows 2000 server sp4) and all
clients connect to it for login. From what I would assume there would be an
msaccess.exe process running on each client machine from the front end file
and thats it, nothing on the server. However I see several (over 10)
msaccess.exe processes running on the server?
1) would clients accessing the access workgroup file (mdw file) actually
cause the server to spawn a new msaccess.exe process?
2) Assuming the answer to number one above is no, I believe this is a
problem related to a scheduled task that runs every night. This task just
launches a different mdb file which runs some nightly update queries. I
think that this file and/or access instance is terminating abnormally and
leaving the process occupying memory. However there are no errors reported
on screen or in the windows event logs? Any other logs, access specfic
maybe, that I can check for errors?
any input is appreciated. Thanks.
| |
|
|
|
| thanks for the reply Lynn. However I'm not clear on your answer. The backend
data is in SQL Server 2000, not access. Sounded like you thought the back
end data is in an access mdb file?
"Lynn Trapp" < ltrapp_NOSPAM@ltcomp
uterdesigns.com> wrote in message
news:uWAUrizSFHA.900@TK2MSFTNGP10.phx.gbl...
>
> I'm assuming that you have a single backend on the server and that that is
> what is creating the msaccess.exe processes. AFAIK, that is normal.
>
> --
> Lynn Trapp
> MS Access MVP
> www.ltcomputerdesigns.com
> Access Security: www.ltcomputerdesigns.com/Security.htm
> Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html
>
>
| |
| Lynn Trapp 2005-04-27, 1:24 pm |
| Yes, I did make that assumption. Sorry about that. I read your post too
quickly. I've never tested it out, but it may well be that the .mdw file is
creating a new process for each connection. A .mdw file is, after all, an
Access database.
--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html
"djc" <noone@nowhere.com> wrote in message
news:%23KZg$3zSFHA.1896@TK2MSFTNGP14.phx.gbl...
> thanks for the reply Lynn. However I'm not clear on your answer. The
> backend
> data is in SQL Server 2000, not access. Sounded like you thought the back
> end data is in an access mdb file?
>
> "Lynn Trapp" < ltrapp_NOSPAM@ltcomp
uterdesigns.com> wrote in message
> news:uWAUrizSFHA.900@TK2MSFTNGP10.phx.gbl...
>
>
| |
|
| good point. Thanks.
"Lynn Trapp" < ltrapp_NOSPAM@ltcomp
uterdesigns.com> wrote in message
news:Og9xC20SFHA.3244@TK2MSFTNGP15.phx.gbl...
> Yes, I did make that assumption. Sorry about that. I read your post too
> quickly. I've never tested it out, but it may well be that the .mdw file
is
> creating a new process for each connection. A .mdw file is, after all, an
> Access database.
>
> --
> Lynn Trapp
> MS Access MVP
> www.ltcomputerdesigns.com
> Access Security: www.ltcomputerdesigns.com/Security.htm
> Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html
>
>
> "djc" <noone@nowhere.com> wrote in message
> news:%23KZg$3zSFHA.1896@TK2MSFTNGP14.phx.gbl...
back[color=darkred]
>
>
| |
| Paul Overway 2005-04-27, 1:24 pm |
| Any process spawned as a result of accessing the MDW will be on the client
(if that is where it actually gets opened). I'd look at your scheduled task
as the culprit for the orphaned processes. Most likely, there is something
that requires user interaction to allow the process to proceed, i.e., you're
using Docmd.OpenQuery to run queries and haven't Docmd.Setwarnings False, or
the database is secure and is prompting for username/password. Something
like that. I'd manually execute whatever you're doing as a scheduled task
and observe where any user interaction is required...and then do whatever is
necessary to ensure that it isn't required when it gets run as a scheduled
task. If you need to determine if the process was completed successfully or
failed, you'll have to trap errors and write to a log table. You cannot
allow any error messages to be displayed during execution.
--
Paul Overway
Logico Solutions
http://www.logico-solutions.com
"djc" <noone@nowhere.com> wrote in message
news:OfmnhY1SFHA.616@TK2MSFTNGP12.phx.gbl...
> good point. Thanks.
>
> "Lynn Trapp" < ltrapp_NOSPAM@ltcomp
uterdesigns.com> wrote in message
> news:Og9xC20SFHA.3244@TK2MSFTNGP15.phx.gbl...
> is
> back
>
>
| |
|
| will do. Thank you.
"Paul Overway" <paul@I.hate.spam.logico-solutions.com> wrote in message
news:uHpYak1SFHA.1040@TK2MSFTNGP10.phx.gbl...
> Any process spawned as a result of accessing the MDW will be on the client
> (if that is where it actually gets opened). I'd look at your scheduled
task
> as the culprit for the orphaned processes. Most likely, there is
something
> that requires user interaction to allow the process to proceed, i.e.,
you're
> using Docmd.OpenQuery to run queries and haven't Docmd.Setwarnings False,
or
> the database is secure and is prompting for username/password. Something
> like that. I'd manually execute whatever you're doing as a scheduled task
> and observe where any user interaction is required...and then do whatever
is
> necessary to ensure that it isn't required when it gets run as a scheduled
> task. If you need to determine if the process was completed successfully
or
> failed, you'll have to trap errors and write to a log table. You cannot
> allow any error messages to be displayed during execution.
>
> --
> Paul Overway
> Logico Solutions
> http://www.logico-solutions.com
>
>
> "djc" <noone@nowhere.com> wrote in message
> news:OfmnhY1SFHA.616@TK2MSFTNGP12.phx.gbl...
file[color=darkred]
an[color=darkred]
>
>
| |
| david epsom dot com dot au 2005-05-03, 3:24 am |
| MSAccess runs on the client. It uses the network
client to connect to a File Server. You do not
normally see an MSAcess process running on the
server at all, unless you are using Citrix or
MS Terminal Services to run your clients on a
Citrix or TS server. You do not normally install
Office on the server at all, unless you are
running TS or Citrix
You may see that Access has established
connections to your file server, but you
don't normally see that unless you know where
to look: it is not what you see in a Processes
list, and the list of connections normally shows
the user and the workstation, not the process
which initiated a connection.
However if you look at SQL Server, you may
see that the connections to SQL Server were
initiated by Access. All connections initiated
by Access to SQL Server do contain 'Access'
in the connection string, and you can certainly
see that if you look in the right place.
But if you are not using Citrix or TS, any MSAccess
/processes/ which are running on your server are
copies of Access running on the server, started
in the normal way.
(david)
"djc" <noone@nowhere.com> wrote in message
news:%23pVRYVzSFHA.3556@TK2MSFTNGP10.phx.gbl...
> (access 2002)
> multi user database with seperate front end mdb file on client machines.
> Data in SQL 2000 Server. However the access workgroup file is located
> centrally on the sql 2000 server computer (windows 2000 server sp4) and
> all
> clients connect to it for login. From what I would assume there would be
> an
> msaccess.exe process running on each client machine from the front end
> file
> and thats it, nothing on the server. However I see several (over 10)
> msaccess.exe processes running on the server?
>
> 1) would clients accessing the access workgroup file (mdw file) actually
> cause the server to spawn a new msaccess.exe process?
>
> 2) Assuming the answer to number one above is no, I believe this is a
> problem related to a scheduled task that runs every night. This task just
> launches a different mdb file which runs some nightly update queries. I
> think that this file and/or access instance is terminating abnormally and
> leaving the process occupying memory. However there are no errors reported
> on screen or in the windows event logs? Any other logs, access specfic
> maybe, that I can check for errors?
>
> any input is appreciated. Thanks.
>
>
| |
|
| thanks for the info. I appreciate it.
"david epsom dot com dot au" < david@epsomdotcomdot
au> wrote in message
news:%23NmpYl5TFHA.1152@tk2msftngp13.phx.gbl...
> MSAccess runs on the client. It uses the network
> client to connect to a File Server. You do not
> normally see an MSAcess process running on the
> server at all, unless you are using Citrix or
> MS Terminal Services to run your clients on a
> Citrix or TS server. You do not normally install
> Office on the server at all, unless you are
> running TS or Citrix
>
> You may see that Access has established
> connections to your file server, but you
> don't normally see that unless you know where
> to look: it is not what you see in a Processes
> list, and the list of connections normally shows
> the user and the workstation, not the process
> which initiated a connection.
>
> However if you look at SQL Server, you may
> see that the connections to SQL Server were
> initiated by Access. All connections initiated
> by Access to SQL Server do contain 'Access'
> in the connection string, and you can certainly
> see that if you look in the right place.
>
> But if you are not using Citrix or TS, any MSAccess
> /processes/ which are running on your server are
> copies of Access running on the server, started
> in the normal way.
>
> (david)
>
>
> "djc" <noone@nowhere.com> wrote in message
> news:%23pVRYVzSFHA.3556@TK2MSFTNGP10.phx.gbl...
just[color=darkred]
and[color=darkred]
reported[color=darkr
ed]
>
>
|
|
|
|
|