Jump to content

jjjjp

Members
  • Posts

    212
  • Joined

  • Last visited

Profile Information

  • Title
    university instructor and program director
  • Industry
    University
  • Gender
    Male

FileMaker Experience

  • Skill Level
    Intermediate
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    Catalina

FileMaker Partner

  • Certification
    Not Certified
  • Membership
    FileMaker TechNet

Recent Profile Visitors

4,269 profile views

jjjjp's Achievements

Community Regular

Community Regular (8/14)

  • Dedicated Rare
  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done

Recent Badges

0

Reputation

  1. A bit of a Catch 22 situation. The reason I have such a low version of FM Server is to avoid asking those users who need access for a small slice of time to go to the trouble of downloading a new version of FM Pro, particularly given that most need to get their IT support people to authorize the install. If I'm not successful in getting WebDirect to work, then I will have created yet more time-consuming work for them in support of a small annual task. I assume that FileMaker Pro 15, won't work with Filemaker Server 19. Or will it? In any case, I will aim to get my IT support to install FM Server 19 (I wouldn't mind getting up to date) and will get back to you if I still can't get basic operations to work in WebDirect. Thanks for all the help so far.
  2. I am having a tentative go at getting WebDirect to work for a minimal # of tasks, and I am stuck right away on portals. Specifically I cannot modify fields in a portal. I don't see anything in the guide that says portals won't work. I've simplified the task to a bare minimum, deleting everything extraneous, and still I can't modify the fields on a portal. Am I missing something obvious? I am attaching the FM file. The WebDirect version can be accessed at https://daviesfm.uc.utoronto.ca/fmi/webd/WebDirectTest Login: Admin Password: Admin Thanks. WebDirectTest.fmp12
  3. I'm trying to figure out the best solution for at least trying to get WebDirect to work for the small # of users who would perform only simple tasks, and I don't quite see how your option 1 (create a separate file that is just for the WD audience) would work, given that the second file would need full access to the database for the original file. Shouldn't I be creating a separate subset of scripts and layouts within the first file and keep everything together in the one file? I would use Get(SystemPlatform) to branch off to a different layout and script on opening if the user is invoking the database from WebDirect. I have no experience using more than one file for a single use case. It seems very complicated, if not impossible.
  4. Many thanks for the suggestions. It sounds as though option 1 would be the more work-intensive of the two but nothing like redesigning from scratch. So WebDirect would interact with the smaller file (file2), which would sit side-by-side on the server with the original, bigger file (file1). File2 would access data from file1. Is this correct? It sounds as though option 2 would be the much easier of the two to implement but maybe pricy for a small operation. Also correct?
  5. I do the lion's share of the work setting up the database each year. One other person does a fair bit, and then there are maybe four other people who do very little, but it is key to have them do that small amount. These people can change from year to year. It would be so much easier if they didn't have to go to the trouble of installing FM Pro for the little they do. I was wondering since my last email whether I could isolate the functionality these people need access to and get that to work with WebDirect. But the small tasks they perform still invoke complicated scripts with layouts on top of layouts, so maybe this is easier said than done.
  6. Thanks, it is very helpful to have a realistic assessment of the difficulty. The database in question is fairly complex, often with multiple layouts laid on top of each other in the course of completing a script. So this may well be too big an undertaking.
  7. I create a database many years ago, and I was very much hoping that the people who use the database would be able to transition from the Filemaker app to WebDirect. However, in my initial testing of WebDirect, many of the things that they will need to click on to carry out an operation result in unresponsiveness. For example, clicking on a radio button set to change a value from "y" to "n" does nothing. Clicking on a button to initiate a script does nothing. Are all of my layout going to have to be redesigned, which is jut no practical (there are so many of them), or is there something I need to be doing to get things to respond?
  8. Ah, great, that’s what I was hoping. Thanks again.
  9. We would all be part of the same organization (a faculty within a university), and the databases would be administered by the same IT staff, but, functionally, there would be no need to stop the databases at once. Both databases would be relatively small without many users at any one time, and the code is fairly stable and so wouldn't need to be updated frequently. If all users need to be kicked out at once, we can probably accommodate that, but it's worth knowing what the options are ahead of time. Thanks for the help, Ocean.
  10. From all open databases, not just mine?
  11. Thanks for the information about how to migrate data without the risk and hassle of importing. I will definitely consider switching. My main concern at the moment is how to avoid having to stop the databases on the server every time I want to update to a new version and thereby interfering with the smooth operation of any other independent databases running on the same server. Are you saying that I can run Data Migration Tool to update to a new version without having to stop all of the databases sharing the server?
  12. I may in the future be part of a shared database that would include two, possibly more, distinct databases, and I would like to have a better understanding of the limitations, if any. Currently, whenever I want to replace my database with an updated version, I stop the database, import the data into the new version, the replace the old version with the new one, and then restart the database. As part of a shared database, would I need to stop activity for all of the other databases on the server whenever I want to update mine? Or is there a way to replace my database without stopping the other databases from functioning?
  13. Thanks. Your item 1 ("the server itself could be configured to not allow outgoing traffic on the SMTP ports") seems to me the most likely. By server, I assume you mean not FM Server but the department server on which FM Server resides. Since the current IT support is very short-staffed now, I am going to leave raising item 3 for the future unless it is a possible source of the failure.
  14. It appear, then, that the blanks fields for SMTP would not be causing the script step from within the scheduled FM script to fail. This is very helpful to have confirmed. So I am going to assume there is nothing in the way FileMaker Server is configured that could be causing the Send Mail command to fail. If there is in fact something else in that configuration that would lead to failure, please let me know? But it appears that the problem lies outside of FileMaker. Thanks.
×
×
  • Create New...

Important Information

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