Hello All,

     A client of ours is running a FileMaker Pro based application
called MaximEyes.  When ejecting a DAT tape manually from the server
the FileMakerPro database on that server becomes unavailable to the
workstations.  The fix has been to stop the FileMaker Server service,
enter the MaximEyes application on the server and set it to
"Multiuser", and then restart the FileMaker Server service.  The
FileMaker Pro database now becomes available.

     For the life of me I can not see the connection between a DAT
drive (they use Veritas' BackUp Exec - I don't know the version) and
FileMaker Pro.

Things to know:

* An "at" command is run every evening stopping the FileMaker Server
service so that BackupExec can backup the database.  A program doing
the opposite is ran at 5:00am the next morning before the employees
come in.

* The FileMaker Server service IS running before the DAT tape is
ejected manually.

* They are running Windows NT 4.0 Server

     It really appears that by merely pushing a button on the DAT
drive to eject the tape the service stops, keeping the clients from
getting to the database.  That's very odd that the two would be
connected.  It's like strapping on your seat belt and the radio
changes the channel.

Any ideas?

Thanks,

Greg Lloyd

I am running Windows NT 4.0 Server, FileMaker Server 3.0 and Veritas Backup
Exec 8.5 with a Travan drive, all without any similar issues.  My only
suggestion is to have Backup Exec backup copies of your databases, rather
than your working version.  The process I use is as follows:

10:00pm - Run batch file

@echo off
if not exist f:\FMBackup goto create
rmdir /s /q f:\FMBackup
:create
mkdir f:\FMBackup
e:\FMServer\FMServer.EXE pause
xcopy e:\FMServer\*.fp3 /s f:\FMBackup\*.fpb
e:\FMServer\FMServer.exe resume

11:00pm - Backup data

The "original" directory (E:\FMServer) is NOT backed up by Backup Exec.
Neither directory is shared by Windows.  The XCOPY command changes the
extension of the databases, protecting the backups from accidental opening
by FileMaker.  With this process, your databases are only down as long as it
takes to make a copy (minutes instead of hours) and are not directly linked
to the backup process.  It may not answer your question (why it is
happening), but it may end the problem.

Good luck!

"Greg Lloyd" <lloydgm@rocketmail.com> wrote in message
news:391c133e.0309121250.269372ff@posting.google.com...
> Hello All,
>
>      A client of ours is running a FileMaker Pro based application
> called MaximEyes.  When ejecting a DAT tape manually from the server
> the FileMakerPro database on that server becomes unavailable to the
> workstations.  The fix has been to stop the FileMaker Server service,
> enter the MaximEyes application on the server and set it to
> "Multiuser", and then restart the FileMaker Server service.  The
> FileMaker Pro database now becomes available.
>
>      For the life of me I can not see the connection between a DAT
> drive (they use Veritas' BackUp Exec - I don't know the version) and
> FileMaker Pro.
>
> Things to know:
>
> * An "at" command is run every evening stopping the FileMaker Server
> service so that BackupExec can backup the database.  A program doing
> the opposite is ran at 5:00am the next morning before the employees
> come in.
>
> * The FileMaker Server service IS running before the DAT tape is
> ejected manually.
>
> * They are running Windows NT 4.0 Server
>
>      It really appears that by merely pushing a button on the DAT
> drive to eject the tape the service stops, keeping the clients from
> getting to the database.  That's very odd that the two would be
> connected.  It's like strapping on your seat belt and the radio
> changes the channel.
>
> Any ideas?
>
> Thanks,
>
> Greg Lloyd

Glenn, Thanks for reading and replying to my post.  Your idea is a
good one, however I don't have a problem backing up the database at
all, it's just when the tape is manually ejected the FilemakerPro
Server stops repsonding to client requests (the FileMaker Pro service
however continues to run).  The rest of the data in my original post
was simply trying to set the scene and may have confused anyone that
read it.

When people come into the office the morning after the backup, the
connection from the clients to the FileMakerPro server is fine.  They
then hit the eject button on the backup drive, and after about 3 mins
or so they no longer have the connection.  Going through the steps in
my original post gets them back up and going, but it's a pain that
they have to do it.

They have to use BackUpExec and a tape backup drive as they've "paid
for it and don't want to buy anything else".

So, that's where I am.  Any other ideas?

Thanks!

Greg

"Glenn Schwandt" <schwandtgat@aoldot.com> wrote in message news:<vmbmjarfgrv4b0@corp.supernews.com>...
> I am running Windows NT 4.0 Server, FileMaker Server 3.0 and Veritas Backup
> Exec 8.5 with a Travan drive, all without any similar issues.  My only
> suggestion is to have Backup Exec backup copies of your databases, rather
> than your working version.  The process I use is as follows:
> 
> 10:00pm - Run batch file
> 
> @echo off
> if not exist f:\FMBackup goto create
> rmdir /s /q f:\FMBackup
> :create
> mkdir f:\FMBackup
> e:\FMServer\FMServer.EXE pause
> xcopy e:\FMServer\*.fp3 /s f:\FMBackup\*.fpb
> e:\FMServer\FMServer.exe resume
> 
> 11:00pm - Backup data
> 
> The "original" directory (E:\FMServer) is NOT backed up by Backup Exec.
> Neither directory is shared by Windows.  The XCOPY command changes the
> extension of the databases, protecting the backups from accidental opening
> by FileMaker.  With this process, your databases are only down as long as it
> takes to make a copy (minutes instead of hours) and are not directly linked
> to the backup process.  It may not answer your question (why it is
> happening), but it may end the problem.
> 
> Good luck!
> 
> "Greg Lloyd" <lloydgm@rocketmail.com> wrote in message
> news:391c133e.0309121250.269372ff@posting.google.com...
> > Hello All,
> >
> >      A client of ours is running a FileMaker Pro based application
> > called MaximEyes.  When ejecting a DAT tape manually from the server
> > the FileMakerPro database on that server becomes unavailable to the
> > workstations.  The fix has been to stop the FileMaker Server service,
> > enter the MaximEyes application on the server and set it to
> > "Multiuser", and then restart the FileMaker Server service.  The
> > FileMaker Pro database now becomes available.
> >
> >      For the life of me I can not see the connection between a DAT
> > drive (they use Veritas' BackUp Exec - I don't know the version) and
> > FileMaker Pro.
> >
> > Things to know:
> >
> > * An "at" command is run every evening stopping the FileMaker Server
> > service so that BackupExec can backup the database.  A program doing
> > the opposite is ran at 5:00am the next morning before the employees
> > come in.
> >
> > * The FileMaker Server service IS running before the DAT tape is
> > ejected manually.
> >
> > * They are running Windows NT 4.0 Server
> >
> >      It really appears that by merely pushing a button on the DAT
> > drive to eject the tape the service stops, keeping the clients from
> > getting to the database.  That's very odd that the two would be
> > connected.  It's like strapping on your seat belt and the radio
> > changes the channel.
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Greg Lloyd

"Greg Lloyd" <lloydgm@rocketmail.com> wrote in message
news:391c133e.0309160620.20be7300@posting.google.com...
>
> Any other ideas?
>

Not really...did you make the change I suggested?  If so, do you still have
the same problem?

I realize that you don't believe there is a connection between your problem
and my "solution" (and I don't know that there is), but seeing as we don't
know what is causing the problem, I can't really hurt, can it?

Glenn, I'll try it as directed.  My issue is that at some point they
still have to hit the eject button on the backup drive.  In your
example you stop fmserver by using the "pause" switch, which is what
I'm doing essetinally but using the "at" command to stop the service. 
I can have them backup from a different location all togethor, but at
some point they have to eject that tape.  Perhaps I'll simply change
BackUp Exec to eject the tape automatically at the end of the backup. 
If that automation causes the same problem, at least we know it's a
service or some peice of software that is also triggered by hitting
the eject button.

I'll keep at it - thanks, Glenn!

Greg

"Glenn Schwandt" <schwandtgat@aoldot.com> wrote in message news:<vme7l9gk77bf5e@corp.supernews.com>...
> "Greg Lloyd" <lloydgm@rocketmail.com> wrote in message
> news:391c133e.0309160620.20be7300@posting.google.com...
> >
> > Any other ideas?
> >
> 
> Not really...did you make the change I suggested?  If so, do you still have
> the same problem?
> 
> I realize that you don't believe there is a connection between your problem
> and my "solution" (and I don't know that there is), but seeing as we don't
> know what is causing the problem, I can't really hurt, can it?