|
David The following idea will not necessarily help you with your immediate problem, but, as you have been an active participant in the Design shift of view Thread, I thought you might be interested in how, conceptually, a Neural Database (NDB) might cope with triggers. Perhaps the most obvious difference between the Neural Database and other databases is that the NDB is data driven: this means that it is always looking for data to keep it "moving". If the NDB looks for a record in a particular context, it will either find one or it will not. This might be regarded as a binary switch. Either situation could be an error. Options in menu records in the NDB could determine what action is to be taken. If there is no record, the NDB might be set up to go back automatically to the previous menu, read the next menu record and look for a record elsehwere, and perhaps continue this process until it finds a record or there is nowhere else to look that has been defined. Alternatively, the NDB might be set up to add a record. This might be done with or without operator prompting and might be a piece of independent data (such as a dimension or a value) or a relationship. The relationship(s) that are valid at this point are also defined in the NDB. If a record is found, the NDB might be set up to move on to look for other data to which the record found acts as a "pointer" (not an address pointer), or it might be set up to delete the record found, or display it to the operator for change, etc.. In either situation, the NDB could also be set up to issue an error message to the operator or call a program to provide a special function not available as standard in the NDB, or it might be set up to roll back a transaction not yet complete and issue a message, etc.. As an example, in a pharmacy, a prescription might be for what in the UK is known as Warferin, an anti-coagulant also used as rat poison. In the UK, and probably elsewhere, pharmacy systems must check previous dispensing history for the patient, even for over the counter drugs such as aspirin. I understand that Warferin and Aspirin together are not a good mix. It is possible using the NDB to set up an unlimited number of contra-indications (I think that is the correct medical term) for each drug and the dispensing application will automatically search the patient's dispensing history. If it finds no contra-indication for the drug being dispensed, it will allow the drug to be dispensed (providing there is enough stock). If for a prescription for Warferin, it finds that the patient has previously been dispensed aspirin at any time, it can prompt the pharmacist to ask the patient if they are still taking them or have any left, before the transaction is allowed or cancelled. All of this could be defined using the NDB which has its own trigger mechanism. No program coding is required. All dates in the NDB would be stored as 9 digits - YYYYMMDDA - where A is an accuracy code, normally set to 5 (exact) for commercial transactions when the date is known. It can also be used to indicate, before, about, after, etc. Options in the NDB indicate how the date (and time if necessary) is to be displayed (in US, European or Julian formats, 2 or 4 digit years, etc.). Times are also stored as 9 digits - HHMMSS.SSA, the last also being an accuracy code. Rob Dixon Erros plc ---------- > From: David Morris <dmorris@plumcreek.com> > To: MIDRANGE-L@midrange.com > Subject: Dates and triggers. > Date: 31 July 1998 20:38 > > Data base experts, > > On files with triggers, it appears as if dates must be valid in the buffer before the trigger is fired. We were hoping to be able to reformat dates entered in an invalid format in either the pre-update/write action. The incorrectly formatted date never gets to the trigger. A date or timestamp exception prevents the trigger from executing. Is there any way around this? We do not have control of every application to reformat the date before the trigger is fired. > > Thanks, > > David Morris +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.