Making Sure A Database Is Running

[Neil]

I need to run a process using a timer. The process needs to be running all
day long. We are looking for a way to ensure that the program is running,
and, if not, then relaunch it.

Some thoughts I had were:

1) Find a utility that runs in the background and checks periodically if the
db is running, and, if not, relaunches it.

2) Write some code in Access VBA or in VB that checks to see if the database
is open, launches it if it doesn't, and then closes itself. The small
program could be launched from Windows Scheduler every 15 minutes or so.

3) Other.

#1 would be ideal. Anyone know of anything like that? I figure there must be
something like this, given the need to run processes continually.

#2 would be fine. But, while I know I can check if Access is running by
using GetObject, I don't know how I would then check to see if that specific
database is open (or if there are multiple instances of Access running).

Any ideas?

Thanks,

Neil

[Ron Paii]

"Neil" <neil.ginsbe...@gmail.com> wrote in message
news:jpet2i$bme$1...@dont-email.me...

If you are OK with Windows Scheduler, have it open you Access program and
have Access exit when done.

[Patrick Finucane]

On May 22, 7:05 am, "Ron Paii" <N...@none.com> wrote:
> "Neil" <neil.ginsberg+newsgr...@gmail.com> wrote in message

> have Access exit when done.- Hide quoted text -
>
> - Show quoted text -

[Patrick Finucane]

If I open the front end, I'll see an laccdb file created. If I open a
linked table, an laccdb file will be created for the backend. When I
close the table, the laccdb file closes in the backend, the front end
still remains. That is one method. To check for an laccdb. If it
does not exist, launch. However, the app could have closed
abnormally the laccdb file could still remain, With the OpenCurrent
database you could set the exclusive flag to True. If no error,
reopen. #2 is a good option I think if you want to roll your own.
.

[Neil]

"Ron Paii" <No...@none.com> wrote in message
news:jpfvdn$h1a$1...@dont-email.me...

Yes, that is the method we're currently using. Works fine. Only thing is,
the process has to be run every 5 minutes on a continual cycle. So my
concern was that continually opening and closing the Access database would,
over time, exhaust system resources. My thought was that just keeping the db
open and having it run on a timer loop would be better. But that would
require some sort of method to guarantee that it was relaunched if it
closed.

[Neil]

"Patrick Finucane" <patrickf...@gmail.com> wrote in message
news:6e4e279a-ea38-4de0...@m8g2000yqo.googlegroups.com...

===================

I like that idea of opening with exclusive access and checking for an error.
But, thinking it over, I'm not sure much would be accomplished by opening an
Access app to check if the other Access app is running, as opposed to just
launching and exiting the main Access app at set intervals through Windows
Scheduler (see my last post in this thread to Ron).

I suppose I could write the checking app as a VB app, which might be much
smaller and might use fewer resources.

Seem I'm chasing my tail here either way by opening a second app to check if
the first app is running.

[Ron Paii]

"Neil" <neil.ginsbe...@gmail.com> wrote in message

news:jpidld$fl3$1...@dont-email.me...

I don't know the API calls, but you could have Access write it's PID to a
text file when started, then delete the file when exiting. Have a VBA,
VBscript, dotNet program check if the program with this PID is running.

[Patrick Finucane]

On May 23, 5:23 am, "Neil" <neil.ginsberg+newsgr...@gmail.com> wrote:
> "Patrick Finucane" <patrickfinucan...@gmail.com> wrote in message

> the first app is running.- Hide quoted text -

>
> - Show quoted text -

My thought would be the second app is open at all times, runs on a
timer.

[Phil]

Private Declare Function apiGetComputerName Lib "kernel32" Alias _
"GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long

Private Declare Function GetCurrentProcessId Lib "kernel32" () As Long

Function GetPID() As Long

GetPID = GetCurrentProcessId

End Function

Function fOSMachineName() As String
'Returns the computername

Dim lngLen As Long, lngX As Long
Dim strCompName As String

lngLen = 16
strCompName = String$(lngLen, 0)
lngX = apiGetComputerName(strCompName, lngLen)
If lngX <> 0 Then
fOSMachineName = Left$(strCompName, lngLen)
Else
fOSMachineName = ""
End If

End Function

Might help, but if Access crashes, the text file will still have the PID.
Might it be worth considering writing a date/ time to a text file, and
somehow checking that it isn't more tham 5 minutes out of date?

Phil

[Ron Paii]

"Phil" <ph...@stantonfamily.co.uk> wrote in message
news:jpiuu4$ql9$1...@speranza.aioe.org...

The PID can't be out of date because it won't change unless the application
is started again. If Access crashes the PID will not be running, so the
checking program can restart the application which will update the file with
a new PID. If the file is missing because the Access application quit
normally, then the checking program can start the application, which will
create the file. The Access application could check for the file to verify
that it's not already running.

[Gloops]

Neil wrote, on 22nd May 2012 04:18 UTC + 1 :
> I need to run a process using a timer. The process needs to be running all
> day long. We are looking for a way to ensure that the program is running,
> and, if not, then relaunch it.

Hello,

Perhaps it would help to precise what you call "the" program.
If you mean ensuring the main database is running, perhaps the calling
procedure could simply have an error handling ?

Or perhaps you meant that the client not running is a problem.
In this case, probably it is more simple to separate the question of the
main database, and simply verify that the client is running.

The APIs can let you see the name of the process, but probably not
ensure that it runs properly. You can imagine it writing the time
periodically in a log. An outside program can periodically control the
time that is written in the log. If that time is too old, the client is
supposed to be looping (endless - you would say looping over ?), and it
seems a good idea to kill the process and relaunch the program. Message
queues are an elegant way for such a link, but it is not quite sure it
is adapted on Access, or even on all system. So, the traditional log
file can do it. Do not forget to purge it from time to time.

And in case of a problem with the main database, what do you think of my
first paragraph ?

[Neil]

"Patrick Finucane" <patrickf...@gmail.com> wrote in message

news:21e50df2-d7db-4de5...@s27g2000yqd.googlegroups.com...

===========================

If the second app were open at all times, then we'd be back to the same
situation: how would we know that the second app wasn't closed or didn't
crash?

So, either way, we'd have to have something continually opened.

I found that the Windows 7 Scheduler automatically opens Access files with
exclusive access. So, having the database file open continuously and run on
a timer, and then having a second, tiny app, that does nothing but tries to
open the main app (which, with or without exclusive access flag, will fail
if the app is open, since Scheduler opens it exclusively), would work, and
would require only opening the tiny app and then closing it again.

However, I'm find that just running the app every five minutes seems to be
working fine. Don't see a noticeable drain on system resources from it. Will
have to see what happens in the long term. Hopefully if we can do a reboot
once a week, that should take care of any problems.

In any case, that's what we're doing now. But if we need to have it running
all the time, then your idea of having the second app which tries to open it
might work fine.

Thanks,

Neil

[Neil]

"Gloops" <glo...@zailes.invalid.org> wrote in message
news:jpkof7$opt$1...@nntp.pasdenom.info...

"Program" = "ACCDB" file.

Thanks,

Neil