Jump to content

Søren Dyhr

  • Posts

  • Joined

  • Last visited

  • Days Won


Søren Dyhr last won the day on December 30 2015

Søren Dyhr had the most liked content!

1 Follower

About Søren Dyhr

  • Birthday 02/11/1963

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Søren Dyhr's Achievements

Grand Master

Grand Master (14/14)

  • First Post
  • Collaborator
  • Posting Machine Rare
  • Conversation Starter
  • Week One Done

Recent Badges



  1. Utility tables are even more impossible structurally speaking, there is no need for transfer more than one or two set of fields from one table to another ... a possible scenario could be what usually in filemaker is known as BOM: http://forums.filema...osts/546709f6c0 Which deals with assemblies of parts being yet another ItemID in the same table ... in other words a recursive table structure, perhaps you should investigate this: http://www.spf-15.com/fmExamples/BilloM.pf7 --sd
  2. Sorry for not seeing this before now - anyways! If your solution have a lot of layouts bearing some kind of similarities could you build yourself a library of those ... the same could be done to the definitions of tables. What could be done is a cloning of an object and then use a straight forward text editor and then make simple substitutions of names of each field ... If you solution just is a tiny bit normalized ... would a lot of things be meat and potatoes in the definitions common to each table. Each should say have at least a keyfield of some kind. In short will a library save you from some of the more trivial typing in matters. One thing you not are able to do sufficiently agile with out the tool is moving custom functions. --sd
  3. Isn't it in the vicinity of the scope of this article? http://sixfriedrice.com/wp/set-field-by-name-exposed/
  4. I kind of suggest that measures should be taken to merge the files into one, and tools exist to perform the meat and potatoes part of it: http://www.myfmbutler.com/index.lasso?p=422 But please note the: --sd
  5. ...exept when they loose track of each other, it's written in your profile that you're on fm5 - which leaves out the option to merge them at all. Please update your profile if needed? --sd
  6. So would I ... I've just lost my bearings being off the tool for a while. It's strange that the sense of balance is the first to go awry - i would have expected a few holes in the rarity dept. --sd
  7. You mean if I go to an arbitrarily chosen record in TestParameter have a won't i get all patients listed - and if I do would the results be a duplication of the first related records data. It seems I've fallen into a classical trap ... Doh what 4-6 month departure from a tool can do with you. --sd
  8. Indeed it should, but it creates a resolve/tunneling issue with drop-downs first getting it's new correct value when the portalrow is committed ... which then would need a event-trigger ... which works by entering the following field, where a note of location should be made before committing the entire record ... for at safe return to the correct "cell". I could be a little rusty on these matter, making me forget a more convenient way ... using menu's instead seems to me a bit ugly. --sd cardiac2.zip
  9. Now this is how I would have structured this ... the next question is how the database is used beyond the actual logging? --sd cardiac.zip
  10. But I'm merely reacting to a point made by LaRetta, to whom it's an issue not to litter a solution with extra fields ... being a summary fields or not. --sd
  11. But I've meanwhile toyed a little with the CF and eventhough summaries have been around for ever and by this fact probably optimized pretty massively ... it's obvious that only current dates loggings have any bearings to the search at all. What I thought was that during such a day is there a max to how many calls to port possible at all, so a CF should only locate when the vessel id changes the first time after a sort. It's then a good question if the overhead to prevent endless looping in a recursive CF is taxing harder than having a genuine summaryfield, eventhough the CF resolves after just a few cycles? --sd VesselLog-3.zip
  12. Well it's not going to be today ... it's moved to my To Do list for tomorrow!
  13. Caps lock is frowned upon! ...and your upload is not working, due to unknown fileformat!
  14. I should be able to do this at some time monday if you should have the required patience?
  • Create New...

Important Information

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