Professional Web Applications Themes

Backup eject harming FilerMaker Pro based Application (MaximEyes) - FileMaker

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. ...

  1. #1

    Default Backup eject harming FilerMaker Pro based Application (MaximEyes)

    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 Guest

  2. #2

    Default Re: Backup eject harming FilerMaker Pro based Application (MaximEyes)

    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" <lloydgmrocketmail.com> wrote in message
    news:391c133e.0309121250.269372ffposting.google.c om...
    > 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 Schwandt Guest

  3. #3

    Default Re: Backup eject harming FilerMaker Pro based Application (MaximEyes)

    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" <schwandtgataoldot.com> wrote in message news:<vmbmjarfgrv4b0corp.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" <lloydgmrocketmail.com> wrote in message
    > news:391c133e.0309121250.269372ffposting.google.c om...
    > > 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 Guest

  4. #4

    Default Re: Backup eject harming FilerMaker Pro based Application (MaximEyes)


    "Greg Lloyd" <lloydgmrocketmail.com> wrote in message
    news:391c133e.0309160620.20be7300posting.google.c om...
    >
    > 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 Schwandt Guest

  5. #5

    Default Re: Backup eject harming FilerMaker Pro based Application (MaximEyes)

    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" <schwandtgataoldot.com> wrote in message news:<vme7l9gk77bf5ecorp.supernews.com>...
    > "Greg Lloyd" <lloydgmrocketmail.com> wrote in message
    > news:391c133e.0309160620.20be7300posting.google.c om...
    > >
    > > 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?
    Greg Lloyd Guest

Similar Threads

  1. Load testing tool for FMS based application
    By dineshawasthi in forum Macromedia Flash Flashcom
    Replies: 2
    Last Post: October 23rd, 10:23 AM
  2. Standalone flash based database application
    By ritur in forum Macromedia Flash Data Integration
    Replies: 8
    Last Post: March 14th, 01:23 PM
  3. web-based application question
    By Pd Schloss in forum PERL Beginners
    Replies: 7
    Last Post: October 15th, 04:13 PM
  4. beginner question doent based application
    By Paul Forgey in forum Mac Programming
    Replies: 2
    Last Post: September 15th, 09:28 PM
  5. Best backup media & application?
    By James L. Ryan in forum Mac Applications & Software
    Replies: 2
    Last Post: July 10th, 04:29 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139