Jump to content

Søren Dyhr

Members
  • Posts

    6,192
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Søren Dyhr

  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?
  15. You're right, it might recurse endlessly, but isn't it just a tweak in the CF only to consider a fixed number of logggings within some sort of reason ... or designing the CF in the gist of this: http://www.briandunning.com/cf/892 --sd
  16. I have a hard time to realize, why this "equalized spread" amongst tables should be nessersary? I deeply apologize if i'm wrong here, but to me that you have way too many fields in one table ... and perhaps would benefit from watching this movie: http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html Since importing between tables inside a solution, only should be considered as a sort of nifty trick - when you can't pull anything off structurally more correct fast enough ... in situations with multiple users stumbling upon each other to massage the same set of data. I know nothing about your age but the methods you seem to subscipe to a past in the 1985'ies where dBase where king of the smaller environment, it could also be the case that you come from a different tool, with it's way of doing things? First off do I need to know what you actually consider logical? Try to attach a screendump of what you would consider the appropriate relational structure we are dealing with there? Perhaps you should post what the present structure exhibit of inadequacies as well ... and let the forum here comment on it, since it's a little difficult to find the mission statement in your present description. --sd
  17. We have grasped this already, but would like to know the relational structure it should be part of ... or rarther would have known, since it can be done entirely independent of the relational structure using a CF instead ... if it then would be particular swifter than the relational approaches attempted earlier on in LaRetta's as well as my contributions is a question wholly dependent on the measure of data in processing. --sd
  18. Would a CF do then, instead of adding fields as well as table occurences ... then I at least could indeed see across records - please scrutinize this attachment... The CF is by the way this: http://www.briandunning.com/cf/497 --sd VesselLog-2.zip
  19. I take it for granted that invoicing the same orderline twice, perhaps is desired ... but isn't sustainable business practice. So some sort of dwindling these away is the key issue to pulling this off, which there isn't particular signs of in you present model ... alright there is an old template of John Mark Osbourne which goes under the name of Serialize By Category, which originates back to 1995 and FM3 - But meanwhile has the tool as such been revolutionized into to lean mean relational tool - which could be exploited. I have here made at template showing how I think I would deal with it, based on a free interpretation of what you have specified - please ask if something is somewhat unclear! --sd P_artial.zip
  20. Ah if thats the case, then should two lines of script, be all i takes - I've tweaked LaRettas template ... --sd VesselLogMOD.zip
  21. To me is it clear that the two fields "First" and "Cleared" is in another table than the Vessel, due to the wording mentioning "4-6 entries" ... and from there is it to make the interaction between the two checkboxes via autoentering in the fields definition. All searches can then be made in the checkboxes table and the found set is then established by going backwards through the relation via GTTR(FS) ... Find attached my first interpretation of the specs.... --sd vessels.zip
  22. It is indeed, what you need to know is that each date corresponds to a certain integer, today is 734151 - what integer do you think tomorrow is? The issue here is to make the result receiving field an appropriate type ... I would suggest number in this case --sd
  23. I would probably lean against this initially: http://www.geistinteractive.com/content/inventory-transactions --sd
×
×
  • Create New...

Important Information

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