Jump to content


  • Posts

  • Joined

  • Last visited

FileMaker Experience

  • Skill Level
  • FM Application

Platform Environment

  • OS Platform
  • OS Version

1Adam12's Achievements


Rookie (2/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges



  1. if what i think you are trying to do is have the content in the right portal change with a selection in the left portal, it's easy. 1st, you need to change your join to the right portal. You need the join to be from a global field that exists in the parent table to the key field in the right portal. then, all you do is have a script that sets the global field to the key field value of whatever record is selected in the left portal and voila, the right portal changes.
  2. it's important to remember that the path parsed by Filemaker must use "/" as the delimiters for Windows paths and not "". If you are using TRFile for example to capture paths, it will capture using "" and after you capture the path, you should do a Subst on it to swicth the to /. This resolves the 'can't save to disk error', too.
  3. That is nifty. I was just trying to come up with a method for this. Works like a charm. Thanks, Danielle!
  4. that's a good point. i tested against the full record set and it seems to be working nicely. thanks again!
  5. ender, your method seems to work beautifully. i'm going to test more with the full record set. easy to get so focused on one solution that one forgets the other skinning of the cat options!
  6. i just got one of the macbooks today (not just to throw at this ) and ran a quick test in fmpa 8.5v1 under os x with my test using 137K recs with my original method. this worked without a hitch, repeatedly. i'm wondering how much of the indexing process is cpu bound. my windows laptop is a 1.6Ghz Pentium M with 1GB RAM. This MacBook is 2Ghz Core2. i'm going to see if i can pull the full record set and test.
  7. i didn't think to try that method with the multi-key join i'm using. method i'm using has always worked...until now anyway. i will test and report. thanks for the insight, ender.
  8. that one is not. it's a text field. gPrintSession is a global.
  9. i've attached a pdf of the script. i think the relationships are ok as the part that tags the record set with the printsession variable works fine and the records show the resulting set value. i'll try to come up with a schema snapshot to illustrate more. Print_Snapshot.pdf
  10. Clients are 8.5v1, 8.5 Adv v1 for me. DB cache is set to max on the server, ~233MB. I pulled a set of the files off the server and ran the process locally on my laptop in just 8.5v1 Adv client and it still borked. I removed 75% of the records, so it was down to about 137K recs, watched as it compacted itself, then did a recover, set index for the field to 'none, automatic' and it still fails.
  11. Hi, I'm trying to figure out if I've got a server bottleneck or if I've got some other issue. I've got a db with about 616K recs that is about 220MB in size. It's FMS8v4 running on an older W2K3 box, 1GB RAM, with dual 1Ghz Xeons and a RAID10 system. This box is targeted for upgrading shortly, so please don't tell me I need some newer hardware. The system CPU monitors never peg, it never runs out of resources, indexing is off, AV scanning is off. I have a function that loops through a portal that displays the results of a complex, multikey join to the above table and writes a unique ID into a temporary printsession field. Then, I call a process that queries the above db for records with that printsession value for a report. Somewhere in the last few months, this script is failing because it can't find any matching records. I've nuked the indexes, rebuilt the file, tested locally. If, after a little bit I do a manual find for the last printsession value, I get the records. Using the dbs from the client side are all fast, no interface lags and users are all happy. Ideas? Does anyone know exactly how frequently FMS does index updates? Many thanks. -A
  • Create New...

Important Information

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