Jump to content

comment

Members
  • Content count

    28,013
  • Joined

  • Last visited

  • Days Won

    562

Everything posted by comment

  1. Relating 2 DB using a range of timestamps

    Do you mean like this? Archive.zip
  2. Okay, I have managed to reproduce the problem. It's a bug. 1. How to work around the bug: Use Insert Calculated Result[] instead of Set Field[]. 2. How to avoid the bug: Save a copy of your file as clone (no records) and import the records into the clone. The new file's date format will be YYYY-MM-DD and your script will work. 3. How to avoid the bug and follow the best practice of not having your script depend on any date format: Make your script do: Enter Find Mode [] Set Field [ Calendar::calDate; Date ( Get (ScriptParameter) ; 1 ; Year ( Get (CurrentDate) ) ) & ".." & Date ( Get (ScriptParameter) + 1 ; 0 ; Year ( Get (CurrentDate) ) ) ] Perform Find [] where script parameter is a number between 1 and 12 (there's really no good reason to send the month name as text, then spend 12 lines of code converting it to a number).
  3. First thing, your file's date format is MM/DD/YYYY. It is set to always use the current system's setting. Are you sure your OS short date format is YYYY-MM-DD? Because if it isn't, that would explain the described behavior.
  4. Could you post a copy of your file with only the date field, the buttons and the script?
  5. I mean perform the script in your file that does "Save a Copy as" .
  6. You're not showing us how the $_range variable is being defined, so there's very little we can say. We also need to know what date format your file is using.
  7. Actually, there were at least four of them: EventScript, DoScript, zippScript and FMI's own plugin example.
  8. You could use the OS scheduler to open a file that does nothing but call a backup script in your "real" file.
  9. Middle letters? Possible?

    Try = Right ( Yourfield ; Length ( Yourfield ) - 2 )
  10. Try the Middle() function: Middle ( full_ticket_number ; 3 ; Length ( full_ticket_number ) - 3 ) If all ticket numbers have the same length, you can shorten it to: Middle ( full_ticket_number ; 3 ; 13 )
  11. Couldn't you simply place the portal in a popover and keep the existing functionality? If you really must go with a popup menu, then define your value list to use values from the URL field, also display values from the Value field, show values only from second field. That way your global field will actually contain the selected URL. Consider also http://www.briandunning.com/cf/908.
  12. Script to send email based on date field

    There is no way you can tell Filemaker to watch a date field and run a script when it passes some threshold. The best that you can do is run a script every day on startup, find the records that have passed the threshold and send the notification/s. You will also want to mark these records and exclude marked records from the find. That way you won't skip a bunch of records when the script did not run for some reason (e.g. on a holiday) nor send a notification twice if you restart.
  13. I presume you create the HTML file by exporting as XML with a custom XSLT stylesheet?
  14. Exporting to Excel with Formatting

    Actually it does mention 360Works' Scribe. This has very little to do with the main topic here. In any case, only fields selected in the export field order are exported. There is no way to point the export to the portal - you need to replicate the choice in both places.
  15. Exporting to Excel with Formatting

    See a previous discussion on the same topic: https://fmforums.com/topic/100534-creating-an-excel-file-from-filemaker-data/
  16. Let me add a general note: Portal filtering is slow - and will get progressively slower as the number of records to filter grows. It is much more efficient to filter the relationship itself. You may think it's not possible because it would require an unstored calculation to serve as the match field on the portal side. However, that is not true: you can define a stored calculation field in the Services table as = Next Service Date - Day ( Next Service Date ) + 1 and use it as the match field opposite an unstored calculation field of = Get (CurrentDate) - Day ( Get (CurrentDate) ) + 1 in the dashboard table, to make only records in the current month related.
  17. The calculation field would be in the dashboard table. However, such calculation field cannot duplicate your filtering expression. How about a different strategy: define a summary field in the portal table as Count of [ primary key field ]. Merge this field in the button text, and place the entire button within a one-row portal to the same TO, filtered by the same expression. Note that a side effect of this is that the button will disappear if there are no records shown in the portal.
  18. You can merge a calculation field within the button text. Therefore the real question is whether a calculation field can determine the number of records shown in a portal. I suspect your portals are filtered, so it's difficult to answer without seeing the filtering expressions. If they're not, it's a simple matter of = Count ( PortalTO::MatchField ).
  19. Many to many reports

    This is not a simple problem. You're up against a blind side of the relational model: the data is there, but it's difficult to display it in the format you require. It is difficult, because no table has enough records to produce the required report. IMHO, the simplest solution here would be to script the allocation of earnings to users as records in a new table. You'd probably want to make this a part of creating an earnings record. Once you have such table, the report becomes trivial.
  20. Many to many reports

    From what I see, earnings are attributed to a project, not to any specific user. And any user can log any number of hours in any project - so how exactly should the earnings be divided among the users? If it's by the number of hours logged in a specific month (as Fitch seems to think), then it gets complicated. BTW, I don't see a date field in the Hours table, so currently you have no way to determine the number of hours logged by a user in a specific month.
  21. It should be include only related values, starting from Program. Note that you'll need to add a ProgramName field to the ProgramCompany table if you want to also show the name in the value list. Or add another occurrence of Program to the graph, and make it the source of the value list.
  22. Problem with File Path Variables

    There are different kinds of file paths. Some of these support the use of variables and some don't. External data sources are the kind that doesn't (until version 16).
  23. Clock / Time Zone Alert

    Ain't that the holy truth. But why do you need to depend on the user? You said this has to do with "users syncing using laptops all over different timezones". I don't know much about syncing, but shouldn't it be based on UTC alone? And if not, what difference does it make if I sync my computer from Rome using Rome time, or do exactly the same thing (sync my computer using Rome time) from Moscow?
  24. Clock / Time Zone Alert

    Then I don't understand your question. Of course you can show a custom dialog saying something like = "Your computer's local time is " & Get ( CurrentTime ) and if you like, you can also calculate the offset by comparing it to Get ( CurrentTimeUTCMilliseconds ). The problem here is that users get used to the alert and will dismiss it as a matter of course without thinking. I'd be careful with the cities, because every city has it's own daylight saving time schedule, and you would have to keep an up-to-date Olson database of your own.
  25. Of course it's possible. It's just much more complicated than what I suggested - and if your purpose is to display a selected program then I don't see a good reason to do it the hard way. But of course you could add a global CompanyID field to the Program table (it must be global so that different users can make different selections), link it to another occurrence of the ProgramCompany table and make your value list show only related values of the ProgramID field from there.
×

Important Information

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