Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About byronic

  • Rank
  1. Cool - we are of the same mind here more or less. I will be recording the data (parameters) as well as the decision. Insofar as historical records are concerned, i am of the view that less is more. One record with all the data you need is preferable to having to maintain a whole database. I speak from experience - I cannot delete an employee, creditor, saleperson, product or customer from the well normalised MS SQl database in my financial system. Consequently 90% or more of the data I am lugging around after several years is irrelevant.
  2. Hmmm. Well I suppose it depends on the likelihood of there being a change to a price between the time of the initial transaction and a later retrieval of the details. If a customer asked for a copy of an invoice 2 years down the track, it would be impossible to regenerate accurately if the product had been deleted or the price had changed. In the IT industry you must take a snapshot of the detail at the time of the order if you want to be able to reliably reconstruct an invoice from electronic records down the track... Let's say that you are monitoring the performance of your s
  3. The warranty status changes over time. A product will usually have an initial warranty, perhaps an extension purchased at the time of the initial order, and then perhaps be under an annual maintenance agreement. In the equipment record there is a calculation field which determines what the status is "right now", and it is this status which is written to the audit record (message record) at the time that a response to the message is determined. If I don't lock down this value in the messages record, the warranty status might have changed when you later review the transaction. The same i
  4. Are we talking at cross-purposes again? The warranty details for the piece of equipment are stored in the equipment table. The replacement parts for a piece of equipment are stored in a separate table linked to the EquipmentType record. Calc fields in the equipment record pull down this info when required. Good example - so my refuelling record would contain a snapshot of the odometer at the time of the refuelling. In this case there may be a dozen or so parameters which are checked by the decision making process - it is these which need to be recorded for audit purposes. eg:
  5. I didn't think i was being condescending - merely stating my case in response to your arguments about what constitutes good design practice. Perhaps you feel that, being new to FM, I should have no views on this. I am not new to RDBMS, or business applications. And I have the grey hair to show for that :-) Perhaps. Anything is possible...
  6. Is it? I am not so sure. I use Lookups elsewhere, but here the values of the fields of which snapshots are required are determined over the course of the decision-making process. (a) The message is received (: Parameters are checked, calculations performed © Decisions are made (d) A snapshot is taken and written to the messages record Perhaps a lookup in a calculation field in the messages table which is fired off somehow in step ©... Dunno. Haven't gotten to that stage as yet.
  7. I think there are many ways to solve a problem with a product as sophisticated as Filemaker. I guess my approach has developed from 30 years or so of building solutions in all sorts of environments, starting in RPG-II on IBM S/3 in 1977. Since then I have worked with a lot of RDBMS products and built systems in many of them. All have their strengths and weaknesses. But here, I think my approach is driven by the view I have of the process. What are we doing here? The answer is we are managing equipment. Various things happen to that equipment - some of which are in response to alert
  8. Actually, it's much simpler than you think. Most of the work in the equipment table is establishing the "facts". Then the decision about what to do about them is fairly easy. The nice thing about this is that the "facts" are all displayed on a layout for anyone who wants to review the process - and the decision making calculation script is quite short and simple for each equipment type. By keeping the logic in the equipment record, it makes the database much less obtuse. For any piece of equipment you can readily see all the parameters which are being considered, and what the decision
  9. When I started looking at this I was not sure I would be able to create a view of the data using information from the messages file. However, thanks to the assistance of the forum I have been able to accomplish that, so no duplicate information from the messages file needs to be stored in the equipment table. But I still need to take a "snapshot" of some of the fields in the equipment, and other, tables and store them in the messages record where they behave as a permanent audit trail, as in the order lines example I gave.
  10. Thanks matey - just figured it out. Didn't know about the unstored part, but its used in an unstored calc field so that's cool...
  11. Solved my problem. Get( CurrentDate ) - LatestAlertDate gives me the answer in days... :-)
  12. LOLOL... I think we have done this to death now... If I place the logic outside the equipment table, or preferably equipment type table, I have to build a script which allows for each equipment type and then calls the appropriate sub-script. If I add a new equipment type i have to remember to change the script and if I delete one, I have to do the same. By leaving the decision process in the equipment table it will always happen when necessary - automatically... It's really about using the power of the database to manage itself - right now i don't have any scripts (except the external
  13. I think we are talking at cross purposes here now anyway. When I first looked at this problem I had not explored very far into FM, and (as you can see from the length of this post) a great deal of valuable assistance has been provided by those who have generously given their time. In my equipment table, I have now defined several fields which duplicate information in the child records. however these are unstored calculation fields. I am still working through the issue of writing data to the child record from a calculation defined in the parent, but I no longer need to write to the
  14. This example is about the pitfalls of duplication fields: RDBMS 101 I guess... However, when I "duplicate" information in my messages table, I am storing the actual value of a field at a specific point in time. The values of these field will change over time in the parent record, and it is essential that these changes are not rolled down to the messages table. A good example of where you would do this is in an order lines table where you "duplicate" the product description, price, weight etc. In the IT industry where products have a life of months rather than years, most of the pr
  15. Each piece of equipment has its own complex algorithm to determine what alerts to respond to, and how to respond to them. It is not just a question of checking more parameters, but of using quite different logic for different equipment types. The processing logic (and parameters) involved in managing the supply and installation of air filters, say, for an air conditioning system (where new filters are required every nn hours of operation, and where the alerts continue until the filter is replaced and a switch reset, but the unit is still functioning) is very different from the processing inv
  • Create New...

Important Information

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