Jump to content

Ender

Members
  • Content count

    4,739
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Ender

  • Rank
    A Space Oddity
  1. Yeah, that's what I want to do. I'm just not sure about the system requirements for the "web server" worker module.
  2. I just upgraded to FMSA9, and now I'm trying to figure out how to get our one XSLT page to work. Our web server is a separate machine running OS X Server 10.3.9. I think this was previously set up using the two-machine (alternate) deployment configuration, with the Database Server and the Web Publishing engine on the FileMaker Server box, and the "Web Server" module installed with the web server machine. So to do the same deployment configuration with FMSA9, will I need to upgrade the web server machine to OS X Server 10.4.x to get the "web server" module installed? I'd hate to have to buy OS X Server 10.4 at this late stage of it's life cycle, since Leopard is coming soon. Would it be easier to just switch to PHP for that page?
  3. Ho Rocky, Yeah, it takes a little trial and error to get used to how FileMaker links elements internally. For most things, they are linked via an internal ID number (that we don't see or have any control over). The advantage of this is you can change the names of layouts, scripts, fields, relationships, value lists, and almost everything stays linked together quite nicely*, even if they are in different files. When you import a script, even if it's a revision of an existing script, FileMaker treats it as a new script, and gives it a new internal ID. This of course means the other elements know nothing about it, and you have to reset any references to it. My suggestion for revising complex scripts is to either do so in your offline version and (1. Redo the script steps in the new version (use Copy & Paste if you have FMP Advanced), or (2. Import the data from the production database into the revised copy. Or, do the work in the production database in a copy of the script, making sure not to run the script in real production records. Then when it's all debugged and approved, change the references on the layouts (or other scripts) to point to the new version. *Exceptions being things that are tied to the names of value lists, fields, layouts, or scripts. i.e. ValueListItems(), Go to Layout[by name], and any conditions you have referring to get(scriptname), get(layoutname), etc. [Edit] Another oddball is stored Import[] mapping. Import mapping is done by the relative order of the fields from their creation order. You can change the names of fields in source or destination file, but if you delete a field, it will shift the import mapping for fields that were created after that one. This behavior is easy to forget, and can cause lots of mischief.
  4. The Go to Related Records[] script step will not change to the destination layout if there are no related records. For this reason (and others) it's good to check for the presence of related records prior to the GTRR call. This is easily done like so: If[isempty(relationship::recordID)] #no related records ... Else Go to Related Records[relationship; layout: whatever layout] ... End If
  5. Backup folder is not a valid path...

    I don't know if it's possible or not (don't think it was possible in FMS7 or FMS8). But you should not do so anyway. Remember: the scheduled backup process is disk intensive, and can cause delays for users. It's best if this backup process is as fast as possible to minimize delays. Backups over the network are also more susceptible to problems, like network congestion or router/switch issues. It would be bad to have your server thinking about how to deal with such a problem while your users wait. The way I'd suggest is to use the scheduled backup capability to backup to a second local hard drive. Then have your third party backup tool (or OS script) move the data to wherever it needs to be for your archives.
  6. Diplay Field From Sorted Portal

    Calculations don't know anything about how portals are sorted (how could they?). A script could, since a script can interact with the layout. But a better method is to sort the relationship instead, then use relationship::field to get the first related field value, or last(relationship::field) to get the last related field value.
  7. Thank goodness! Now comment can go home knowing that a ¶ is a return, and all is right in the universe. Whew, that was a close one!
  8. Hey Elise, I don't know if this is something you've already tried (or if it would work), but maybe try a global text field, and enter a in it. Then use that field as the separator in the calc.
  9. <throws hands in the air>

    It will be helpful if you can describe the keys and the relationship in detail, and provide example data that works and doesn't work. Maybe post a screenshot of the relationship graph or a clone of the file.
  10. Sharing Filemaker as a host

    It sounds like you might be opening the file from a network volume. This is not the way to host a FileMaker solution. The host machine should have the file(s) stored on a local hard drive. In the file's Sharing settings, you can turn on Network Sharing and also enable the 'Access via FileMaker Network' extended privilege bit for each privile set. Each workstation will then connect using File->Open Remote (or an opener file). When they do so, they should be prompted for an account and password.
  11. For the most part, FM9 is backward compatible with FM7 (it uses the same file format) and runs everything the same. But there are often unexpected differences between running a file as stand-alone and running the same file in a hosted, multi-user environment. Particularly, the behavior of global fields in the way they retain (or don't retain) their values from session to session. There are also record locking issues to be aware of.
  12. Hey, how about that. I didn't realize that was the famous "fast summaries" technique. Man, I gotta read more of those off-forum articles.
  13. Here's a general description and algorithm for assembling summary record data into chart strings: http://fmforums.com/forum/showtopic.php?tid/190507/ For FM7 compatibility, use global fields instead of $$variables. Once you figure out your getsummary() average, you can pop that in there for the X data (how you're getting your average is not clear enough to me).
  14. Is there a faster way?

    So how long does it actually take?
×

Important Information

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