Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About merkaba22

  • Rank
  • Birthday 01/14/2006

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, thanks all for the tips -- I suppose that I could go back to the last saved DB prior to my recent but minor mods, and re-do the work with the hopes that that will remove the source of corruption (since there is no way to diagnose the issue, per se) prior to making the decision for a full re-build.
  2. Thank you for that -- is there a methodology where a file can be recreated by copying over layouts, importing tables (with fields definitions, etc) and relationships before, as the last step, using the script importing feature that has been part of FM for some time now? Is there any information I can review?
  3. I did some work on a legacy system some time ago where I copied the file to my Mac. In witnessing the aberrant behavior on the subject file the other day, I showed the client the issues I faced by creating new fields as described above on the old (less developed) copy wherein it could be demonstrated that in the old FM the solution worked correctly and, now, only within sometime in the past 7 days, since I last visited the client for a few minor mods, the solution is working improperly as described above. I hope that clears that up. None the less I, since I do not claim to be all knowing, would like to revisit the technique for recreating the file without re-writting it from scratch that I read about earlier this year and have never used. If there is some other way to "de-corrupt" a file, other than the built-in tools FM offers, I would be very appreciative all positive suggestions.
  4. The client does not have a "golden master". I read here last summer (and searched for and did not find) about a procedure based on additional features in 11 that would make such a rebuild easier -- I am looking for that. When I evaluated the solution, I created a new test field and added a checkbox along with appropriate settings and could not modify the field -- on my personal copy, I could. Data entered in portals disappeared and scripts for deleting each line item failed within a few minutes of entry, etc. whereas a week ago none of this was happening. The host Mac Mini has not been maintained in years, has way too little RAM and is used for other purposes against my recommendations/economic considerations outside my control. I seriously suspect the Mac is the cause and want to rectify the DB asap.
  5. I looked at the file again this afternoon and found scripts not running as intended and not being able to click in fields that otherwise are defined appropriately -- even newly created fields. I am quite confident that the relationship keys are not the real issue. I am looking for a specific method to create a new file, copy over the layouts and field definitions, and, if possible, the relationship mapping to ensure that there is no corruption ... whereupon I can import the data for the various tables, etc. and restore the solution and its data to a fully working version that existed prior to a few days ago. It was my understanding that this was possible with FM 11 -- I am looking for that specific technique.
  6. In a three year old FM database there are portals for data entry within a parent file and this design has been working fine until recently. Now, in at least two instances, the relationship key data in the child (portal) files have been lost/corrupted and the data no longer displayed in the parent file portal; if the keys are manually corrected, the data displays as it should. I suspect some form of file corruption -- and I wonder if this is a good time to "rebuild" the solution and, if so, what the preferred method for this would be. I am using FM 10 but could upgrade to FM 11 if it would help. Thanks in advance.
  7. In a small network with a new 22.5" iMac w/4GB serving FM 9 to 2 older iMacs w/2GB running 8.5 for a file about 50MB with 13 tables and the main "data" table having 64 fields and 79K records to date. All the scripts and relationships seem to be running fine but there seems to be an unusual data corruption issue -- sometimes a portion of the 79K records disappear while not crashing the computer or the file -- the file has been "recovered" using FM 11, compacted, copied to another disk and back and the processed repeated, Disk Utilities/Permission run, etc.; early on, about two weeks ago there was a repair via "recover" that was assumed to address the oddity, but the issue remains: Yesterday, a user on one of the two older iMacs observed that in one moment all the records were there, turned her head (there were no other users at the time and FM was idle) and when she looked back 5 seconds later, all but 4600 records were missing and the file size dropped form 50MB to 17MB without crashing. The other tables were fine. Its been recommeded that FM Server on a MacPro w/ 4.5 GB RAM and a separate drive for the solution where the data table is separated out to a second file will resolve. Any ideas?
  8. So, if I understand this correctly a file/solution can be written with script triggers, say in FM10, be served successfully with any client version of FM from 7 upwards where the script triggers will work with any client machine running 10 or higher?
  9. In a small network of two Macs running FM 8.5/FM 9, networked to a third Mac acting as a server via client software, will FM 10/11 script triggers be executable by the clients when they are running the earlier versions of FM?
  10. The reason my main file is not working using your model is that the records in question are portal records and share the same ScheduleID -- need a new model or create a "record_ID" and run a script through all the portal records and assign a unique value to each ....
  11. Thanks Comment, you've been great -- I made a test using your concept and it works -- I will troubleshoot why the main file does not. Not sure how to attach a FM7 file of the working test model.
  12. Still don't see it -- tried other relationships and calcs in the validation, but somehow, today, at least, this escapes me.
  13. Ok -- set up the relationship based on Date, Name and Schedule_ID as directed above using: StartTime (using leave data formatted) as a time field auto-calc: Time ( Left ( Time ; 2 ) ; Right ( Time ; 2 ) ; 0 ) and EndTime (using leave data formatted) as a time field auto-calc based on duration: Case(ride_duration_calc = 2; (Time ( Left ( Time ; 2 ) ; Right ( Time ; 2 ) + 60 ; 0)); (Time ( Left ( Time ; 2 ) ; Right ( Time ; 2 )+30 ; 0 ))) So that if Time = 0900, then StartTime is "9:00:00" and EndTime (where duration is "2") is 10:00:00; Validation for Name: not Schedule_2::Schedule_ID And still it seems to validate no matter the entry -- what did I overlook?
  14. Thanks Comment -- this is very interesting and I will attend to this today:)
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.