Jump to content

Timothy Moser

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Timothy Moser

  • Rank
  1. It seems to work just fine now. Great, I just had a whole discussion with myself on a public forum. But at least now a Google search for "cwp php custom privileges" points to a relevant spot. I guess it's nice to help others while I help myself… -Timothy Moser the Self-Conscious
  2. Hmm… I just did the experimenting I should have done before posting this, and I figured a few things out. First, the idea that custom privileges do not work in PHP CWP is a myth. They work perfectly as far as I have been able to tell. In my situation, I had a bunch of privileges calculated based on a global variable ($$User), which is set in a FileMaker startup script as Get(AccountName). Apparently startup scripts do not run automatically in PHP CWP (which makes sense), so I added running the script to the code. It still didn't work. I guess it must have something to do with the
  3. Is it true that custom privileges do not work in PHP CWP? I read that somewhere, but I couldn't find any more information about it. I have several users with a custom privilege set in my database, and I haven't been able to get it to work with my web pages, so I thought I'd ask the experts. Thanks, -Timothy Moser
  4. I am on FM Pro 10, I just switched to a Leopard computer, and I get the message even after deleting the file. Your solution worked perfectly on my previous computer, but I cannot figure out what is wrong now.
  5. I am doing more backups now so that I do not have to use recovered file. The file I am currently using is based on a file that was once recovered, but it seems to be fine. Thanks for the advice.
  6. Is there something wrong with restored files? I have been testing mine and they do not seem to have many problems, although sometimes things will be missing and I have to add them from previous versions of my database.
  7. Fixing some problems in the script seem to have solved the problem. Thanks for your help. Still, I do not understand why opening the record one way is different from opening it another way.
  8. Hold on; you were right. There actually is a script trigger that activates when a record is committed in this layout, and turning it off fixes the problem. I just have to figure out why the problem only happens when the record is opened a certain way.
  9. Selecting the script from the menu does the same thing. Incidentally, there is a global field in the table that displays on the layout, and whenever I commit the record after having used the script to open it, it looks like the global field is selected while the program sits there frozen. Could that have anything to do with it? It still does not explain why the single-line script is different from simply modifying the record. Edit: No, deleting the global field from both the layout and the database did not help.
  10. Is there a difference, any difference in the world, between editing a record by clicking on modifiable fields and editing a record by running a script that uses nothing more than the "Open Record/Request" command? I have a problem with FileMaker crashing when I commit records in some of my layouts. It freezes, and if I force quit it and restore the file, I find that it has added thousands of empty records to the tables. But the thing is that this only happens if the way I first got into the record is when I have used the script. I reduced the script to one line, "Open Record/Request",
  11. I would rather not do that, but I can say that I just narrowed down the specific privilege that was causing the problem. The way I originally had it, the users could only view the records that met a specific criterion that referenced a related field. When I took this requirement away and gave them viewing access to all records, they were able to perform finds. Again, this was only on the web; the same users were able to perform finds in FileMaker before I extended their privileges.
  12. See, I do not get this. In my case, the find (for just one of the tables, not all of them) would not work unless the fields were modifiable. I turned on "prohibit modification of value during data entry" to prevent users from actually modifying real data, so I think my problems are pretty much fixed here. You just have to keep changing things if the database does not work on the web.
  13. I got it to work by granting extra view privileges that were not needed in FileMaker but that I found necessary on the web. The moral of the story (this topic and the one I posted along with it) is that users need extra privileges on the web. Remember: test, test, test. The web does not work the way FileMaker does, and FileMaker's documentation does not catalogue all the differences.
  14. Alright, now it works when I grant the user the ability to modify fields. For some reason they only need this privilege on the web, not in FileMaker. I do not understand that.
  15. OK, it is not just the layout; it seems to be the table. No search on any layout for that table will work for a limited-access user on the web. Let me see if I can figure out what is wrong with the table.
  • Create New...

Important Information

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