home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / appletal / 3869 < prev    next >
Encoding:
Text File  |  1992-11-10  |  2.2 KB  |  56 lines
  1. Newsgroups: comp.protocols.appletalk
  2. Path: sparky!uunet!pgroup!lfm
  3. From: lfm@pgroup.com (Larry Meadows)
  4. Subject: Filemaker Pro and Macdump summary
  5. Message-ID: <BxIwxv.Cpp@pgroup.com>
  6. Date: Tue, 10 Nov 1992 23:22:43 GMT
  7. Organization: The Portland Group, Portland, OR
  8. Lines: 46
  9.  
  10.  
  11. I got one request for further information from a gentleman at LLNL, but didn't
  12. save the message (sorry!).  I also got the answer (Thanks, Kevin!):
  13.  
  14. In article <BxAwIx.Bv1@pgroup.com> you wrote:
  15. : 
  16. : <STUFF DELETED>
  17. : Seemed to work ok, but then we found that one of our Filemaker Pro (2.0)
  18. : files was 0 length!  This file changes every day, so we went back one day
  19. : on the incremental -- same problem.  Went back one more day, to Friday
  20. : night, and the file was there.
  21. : 
  22. : The guess is that a network user left the Filemaker Pro database open
  23. : and the Dumper was unable to read it.  So I have several questions:
  24.  
  25. This is something that I have come across here at the SSC. In the library
  26. there are four big FMP datafiles in use. If they are not closed down
  27. they come up the same way. According to the folks at Claris this is
  28. because FMP flags the file as open and makes it to where no other application
  29. can do anything (include passive read) to it. So the senario is that the
  30. backup program (any backup program) gets the directory entry but no data...
  31. wala...a zero length file. So its not really a backup program issue but a
  32. FMP issue. One workaround....do your backup through an apple event type
  33. program (Frontier or QuickKeys) and force a close of the Filemaker
  34. Application before the backup program runs.
  35.  
  36. What a rotten way to find out about FMP backup strangeness. Good luck on
  37. your data recovery.
  38.  
  39. : 
  40. : Thanks in advance, I'll summarize if it looks worthwhile.
  41. : -- 
  42. : Larry Meadows        The Portland Group
  43. : lfm@pgroup.com
  44.  
  45. Kevin Dunn (kevin_dunn@qmail.ssc.gov)
  46.  
  47. So I guess one must close the databases if correct backup is expected -- and
  48. it appears that NO backup program will work any better.  Of course, if I
  49. put the files on Unix then there will be no trouble -- but I have a hunch
  50. that FMP won't necessarily work correctly in that case.  On to 4D+Oracle...
  51.  
  52. lfm
  53. -- 
  54. Larry Meadows        The Portland Group
  55. lfm@pgroup.com
  56.