Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Ender

  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. 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. 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. 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. 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. So how long does it actually take?
  15. And while looping can be slow, that alone wouldn't explain why this process would be slow for only 2500 records. You didn't say how "long a process" it is (5 seconds?, 30 seconds?, 5 minutes?). One other thing that can be a slow process is deleting records, especially if there are cascading deletes involved. If you don't need the cascading deletes, you might disable that in the relationship definition. Another option is instead of deleting the records, mark them as "inactive" or something, and filter them out of your relationships and Finds. This would effectively hide them from users and processes. You could then deleted them for real at some other time (or leave them in there).
  16. Looping can be a slow process. If you only need to update a subset of records, try finding only those records first, then update only those. I can't say specifically how to do this in your file as it's missing the important structural bits. Also, the Go to Record Request [ Exit after last; Next ] should not be necessary after your Delete Record[]. This will cause the next record to be skipped.
  17. Don't have the files set to automatically login (in File->File Options). If they log into the first file, the others will inherit the login settings from the first file.
  18. Sorry no. You should host the file using FileMaker Pro or FileMaker Server on a dedicated machine and have each workstation log in to the hosted file using their own licensed copy of FileMaker Pro.
  19. I haven't setup such a system, but I won't let that stop me (I need to figure out my own budget anyway, so this might be useful for me ) First, stay away from repeating fields for this. They won't give you the flexibility you'll need later for building reports. Instead of repeating fields, use a portal of related records. I'd imagine you'd have a list of items for each month, and each item would be assigned a single main category. It sounds like you also have a set of annual expenses that are also assigned to main categories. Would it make sense to pull out the annual budget items into a separate list, or do you want those assigned to a specific month? Structurally, I'd think it'd be easier to assign things to specific months. But it's good to keep an open mind and try to think through the business processes first. Are there different budgets for different departments, or is it one general budget?
  20. Yeah, sounds like a bad idea. An email with over 1000 (or even over 15) is likely to get stopped by spam filters, or at least is more likely to be stopped by spam filters.
  21. There should be no need to pass accounts and passwords to the other files. The current account and password from the parent file will be used to open the other files. Instead of using Open[], you might try Perform Script[External] to call an opening script in the other files.
  22. I think you would either need to use a calc field that concatenates your field and whatever determines it's order, then List() that (and sort it and parse it later, probably using CFs), or use a looping method to build the list. It's probably simpler to use a looping method.
  23. No to both. FileMaker files should be opened locally (that means stored on the local hard drive), and "hosted". Other clients would then access the file through "Open Remote", a specific Open command located under the File menu (or in the Open dialog).
  • Create New...

Important Information

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