Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About db_tragic

  • Rank

Profile Information

  • Gender
  • Location
    Adelaide, Australia
  1. Unfortunately duplication is necessary - I work in healthcare, and the growing regulatory environment dictates a lot of information to be recorded each consult. Much of the data is very similar from one visit to the next, however some of the data isn't, so easier to duplicate the previous visit, and alter the variable data as needed. As it is, I realised when driving home after my post, that a catch-all copy/past would be problematic, as it would include primary and foreign keys also which would be unique to the previous record. As it is, I think I have found a better solution by creatin
  2. OK, so I want to expand on this script a little further now. Scenario: Each record (in a found set) has over 25 fields. Objective: To copy over the values of all of these (N - 1 record) fields into the current (typically a new) record. Question: Instead of applying the suggested script line(below) for each field, is there an expression that will allow me to copy all fields over in one go? I'm just hoping for something shorter and tidier than having to retype this for each field. Set Field [ YourTable::Notes ; GetNthRecord ( YourTable::Notes ; Get ( RecordNumber ) - 1 )
  3. Thanks for that comment - haven't got round to applying suggested solutions as yet. That does look like a tidy one though, thankyou.
  4. It is the previous record in the current found set, sorted by date (descending).
  5. Thanks for that Webko - I'll give that a shot tomorrow and see how it goes.
  6. I'm looking to place a button on a layout whereby it causes a given field to be filled with the value entered in the corresponding field from the previous record. e.g. I'm creating a new record for a client's consult notes, and the 'notes' field for the previous visit(record) need to be carried over to the current entry. This is not always the case, hence I don't want it to be copied over automatically when a new record is created. Hence a "Copy Previous" button will give me the option. Struggling with figuring out the right expression/s to use to build the appropriate script for the
  7. Thankyou for that - starting to make sense now. I've not really considered using a portal at this stage, only because I prefer the visual appearance of a simple list of inventory items, with a set of radio buttons on the same line as each item. (I did this in a simpler version of this database, which only had the one table (Inventory) and didn't include attributing a pack list to a given trip. Adding the Trip table, (and separating Pack List into another) which I'm doing now, I'm trying to keep to a similar format if possible. Ok, so I've set up the relationships as Luis suggested
  8. Given the filter here is based on the balance amount, which field do I specify in the constrain? (Still learning about finds) Using the amount due isn't working for me. I then have the challenge of setting the script to restore the intial find so that when an alternate filter option is subsequently selected, the new find doesn't constrain the existing found set. The relationship structure is below: Basically, on the Client Details layout, I have a button (script trigger) that takes me to the transaction listing layout; Go to Related Record [Show only related records; match found
  9. I have a layout set in list view, of transactions relating to a given client. I have set up a drop-down list containing the following filter criteria: Show all Show unpaid Show in credit Show paid I'm having trouble setting up a script (script trigger based on the drop-down list) that filters the currently displayed transactions for that client. At the moment, selecting any of these filter criteria, causes the filter to apply to all transactions for all clients, and are not being applied to only those showing in the transaction list. Selecting 'Show All' after selecting any of
  10. Thanks comment, Ok, so I've rearranged the relationships (see end of post), but have struck a challenge setting up a Pack list against a trip. I've set up a 'start screen' which includes buttons to view a list of Trips entered, or create a new one. In the case of creating a new trip plan: I want to go to a layout called CategoryList, (a list view of the inventory, by category), which would show all items in the inventory, on separate lines, and on the same line as each inventory item, three "Yes/No" fields corresponding to "To pack?", "To Buy?" and "Packed?" First, I need to
  11. Just can't quite seem to get my head around this - though it will likely be a "Doh!" moment when someone comes up with advice. Scenario is as follows: I build an inventory of items I keep for camping. For each trip I do, I want to keep a track of what I plan to take/took. My initial thoughts were: 3 tables (with fields) 1. Inventory (contains fields such as Item, Category, Stored Location, Packed Location) 2. Trip (Trip name, Date, Duration, Season, Expected weather, Actual Weather) 3. Packlist (To Pack?, To Buy?, Packed?) The way I want it to function is this: I build
  12. Hi comment, Thanks for making that distinction. That's a good clarification. Cheers,
  13. Thanks for clarifying that. I can clearly see your point as I look at it now. When I started on this database project 18months ago, I understood far less than I do now (in fact it was my first real go at a FileMaker solution), hence the slip up. Knowing what I know now, I would have done just what you had suggested. Perhaps I should review a few of the things I did earlier in case there's other issues there I haven't seen yet! Hmm - I got this advice earlier from 'comment': http://fmforums.com/forum/topic/90981-filter-field-in-list-view-using-drop-down-menu-items/?p=417857 Perh
  14. My understanding though is that you can't use a calculation in a find - so I found out earlier, hence I've tended to not go down that road (using a scripted find). (I'm still getting my head around some of the nuances of using finds - probably will be doing that for some time to come too!) Nonetheless, thanks for the thought.
  • Create New...

Important Information

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