Richmilnix

Members
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Richmilnix

  • Rank
    member
  • Birthday 07/25/1971

Profile Information

  • Gender
    Male
  • Location
    Otherville, ME

FIleMaker Profile

  • Profile Updated
    01/03/2017
  • FM Application
    15 Advanced
  • Platform
    Windows 10
  • Skill Level
    Intermediate
  • Title
    Developer
  • Industry
    Public library

Recent Profile Visitors

2,141 profile views
  1. I might have confused things (again) by typing the script manually. The script step actually reads Go to Layout [ “staff_schedule_match” (Date_match) ] where Date_match is the named relationship through which my portal is seeing the employees working on a given date. . . . and therefore, I now realize, I need the relationships in the script to be defined through Date_match as well! I gotta admit, I still get confused in trying to map this out. But the solution is working now. Thanks for your input.
  2. I know it's hard to tell because I threw so much information in there, but staff_schedule_match is one table, containing shift data that looks like StartDate: 3/22/2017 StartTime: 7:30 AM EndDate: 3/22/2017 EndTime: 4:45 PM nUID: V204 A second table is the one I'm working in, staff_schedule_interface, intended to be the neutral "window" through which employees view and print the data in above (organized by day, by week, or by name). Given the use I described above, I don't understand what context I should establish. (At least once, I solved a problem by creating a field called "1" in both tables, defining it as a calculation whose value was 1, and using that to build an "everything is related to everything" relationship. Not proud of that.)
  3. I'm reframing a question that I posted in a confusing way. Using variables seems so simple to me, but I know I'm missing something. I'll just post exactly what I'm trying to do so you guys can tell me why it isn't working. The project is a db that will handle shift schedules for employees. In the one-day view I'm looking at, the essential live field is a global date field called gDate_of_work. A portal is looking through to related records and returning a list of employees (from a table called staff_schedule_match), identified here by unique serials, who are scheduled to work that day. There is a second portal, located on the same layout, that is (correctly) showing a separate related list, of employees who are available to work on the day of the week. I, of course, want to be able to click on the name of an available employee and pass her serial number, along with the date in the global date field, to a new record in staff_schedule_match. In the distant past, I've sometimes solved this by opening layouts in offscreen windows and having extra fields dedicated to this data transaction, sometimes even by using the computer's clipboard (i.e. copy/paste). The script I'm trying to execute here goes: Set variable ($shift_add_nuid; employee's serial number from related record two) Set variable ($work_date; date displayed in this global date field) Freeze window Go to layout staff_schedule_match New Record Set Field (staff_schedule_match:nUID; $shift_add_nuid) Set Field (staff_schedule_match:StartDate; $work_date) Set Field (staff_schedule_match:EndDate; $work_date) Commit Record Go to layout (original) Refresh window Stepping through the script watching Data Viewer, I can see that the correct data is getting loaded into the variable values, but I can also see that the destination fields show up with an Unrelated table error. I don't understand why - I expected the behavior to be destination-agnostic, like my computer's clipboard, where if I copy some text in an email, I can paste it into a word processor or a browser or whatever.
  4. You're right; I was conflating two issues (because I thought my variable trouble was stemming from my mixed-up TOs). Reframing my question in a new thread.
  5. All right, let me try to answer without digging myself any deeper. First of all, I'm not arguing with you guys. Clearly, I overcomplicated things. But since Wim asked what I was after: I'm a part-time developer who only dives back into FMP every few years when I have a problem that needs solving. That means that I don't spend a lot of time thinking about logical schema. As my projects began to grow more sophisticated and more interrelated, I found that my relationship maps were sprawling - mostly because what had started off as a db hosting events was now also hosting staff schedules, and now was also incorporating POs and invoices, and everything seemed to be related to everything and my relationship graph looked like a child's drawing of a millipede cocktail party. So in short I was trying to neaten things up. I'm still (I guess) a bit mystified about some of the complexities of relationships. Even after straightening out my separate TOs, I still have questions about passing variables, so I'll post back later about them.
  6. You know what, I have only myself to blame - years ago reading about Anchor-Buoy structure I Was really attracted to the notion of discrete TOs coupled by a slew of relationships - but each time I try to implement them I make sort of a hash of it. Thanks for your input.
  7. My goal here is to write a database with tidier relationships than I've used in the past, so I'm intending to use discrete table occurrences of the same data. Here's the roadblock: In layout 2_week_schedule, I have 14 portals that display a staff schedule (two weeks' worth) and can't be edited. My goal is that a logged-in administrator can click on the date field of any one of those fourteen days and go to a layout 1_day_schedule that is displaying the same information, though with more details and one day at a time. The underlying table of each layout is the same, though the layouts are based on different TOs. I wrote this with a script trigger in the date field in 2_week that fires a script to copy its value as date to variable $date, switch to the 1 day layout, and set the pertinent date field there to variable $date (and then commit).I don't know if it's my error, but I think of variables as being like my computer's clipboard - any value can be copied & pasted to/from. But the script fails with the message The operation could not be completed because the target is not part of a related table. I did try a simple redundant relationship (connecting the two pertinent fields), but that was a hail Mary, and didn't do the trick anyway. Is there a better way to accomplish what I want? In short, I want administrator who's scrolling through the existing schedules to be able to look at any date where she wants to make a change, click on it, grab its contents, and be brought to a more flexible interface where its contents get inserted into a portal that will then show her the results. This file is web-accessible, so I can post its address if it helps to see what I'm talking about.
  8. But - and I don't mean to be thick, though I may be - is there precedent for layouts, made using the native FMP interface, and accessed via WebDirect - as the main method of accessing the db interface? Are people making that? The last time I was neck-deep in this thought process, the www interface was too cumbersome to make that a satisfying experience.
  9. This is a wide open question without a correct answer. Maybe it will foster comments & suggestions. Over several years, at another job in another state, I cobbled together a FileMaker solution that's now an essential part of the way that business operates. That project consists of several haphazard fixes and relationships held together with baling wire and chewing gum, because we kept ading functionality as it occurred to us, and because my skill level was changing as the project grew. Now that I'm in my next life, I'm ready to start the project from scratch and try to license it as an off-the-shelf database to businesses in this line. I'm convinced that the right form for such a project is a browser interface. So my question: is there such a thing as a solution, sitting on an FMS install, that's solely accessed (by its users) via a browser window - and doesn't feel clunky? If I were a newborn, just wanting to make this project, I'd assume that the best thing was to learn PHP & Ruby & JavaScript. I'm not assuming FM is the best way just because it's what I know, but et cetera et cetera. All input, as always, is welcome.
  10. Thanks, Wim, I was genuinely confused by the "for teams" layout.
  11. I didn't see any subforum that's specifically devoted to FileMaker as a product. If this is in the wrong place, sorry in advance and feel free to shush or move me. It's a few years since I spent money on FileMaker, but I'm considering recommending it to a public library and am bewildered by the current store offerings. I expected to find renewable annual licenses for 4 or 5 seats of FMP, 1 of FM Advanced, and then talk about the pluses and minuses of hosting on 1 seat of FMS. Instead, I'm finding group subscriptions, no mention of Advanced, but something else called Developer. Can anyone point me to a rundown of FMP's current suite of offerings?
  12. That's exactly it! I was getting so caught up in the "higher order" scripting, I was forgetting that when users open it, they click a button to indicate which interface they want to use. Simple added command going to the right layout did the trick. Thanks
  13. TL; DR: FMS running scheduled script to delete "extra" records, reports success, records not deleted. ----------------------------------------- I had a persistent problem: people opening a database weren't realizing they were looking at other users' existing records, and were inadvertently overtyping them. (More than half the time that people access this, it's so they can make a new entry.) My solution was to have the DB create a new record each time users accessed it (via a certain layout). The empty records aren't a problem (because users only access "old" records through a search function or printed reports), so I wrote a script that searches for, and deletes, empty records. The only goal is to keep the chaff from outweighing the wheat. This has worked fine. When I schedule the script (in FMS 14.0.4.412), FMS reports success, but when I reopen the db on my desk, none of the 'useless' records has been deleted. When I run the same script manually, it runs fine (the records vanish). The account running the script is a Full Access account, and the script has full access privileges. ------------------------------------------- The steps involved in the script are (how do you cut & paste a whole script?) - Set error capture on - Perform find on a calc field (flips from 0 to 1 when all three fields are empty) - delete all - commit - show all - go to last record
  14. No, I'm in over my head. ODBC driver I get, but I don't know what DSN stands for. Desperate, Stranded Newbie? There are plenty of kinds of FMP sharing that are one-step operations that are easily executed on the first try with no special knowledge (like converting from XLS). I was assuming this would be one of those, since SQL is open. For now, I'm going back to first base
  15. A simple project wants to start with several people out in the field doing data entry; in the interest of uniformity, I set up a simple one-table web-based SQL table with a one-way PHP interface. That's working fine (and is about the limit of my facility with PHP). My intent was to set up an automated recurring import into a FMP database, which I thought would consist of entering credentials and an IP address into the ExecuteSQL script step. I find the learning curve a little more steep. In this instance, it's really not hard for me to export the contents to my desktop once a day and then hoover them up into FMP. But can you recommend a one-stop tutorial for this kind of straightforward behavior?