How do you deal with the issue of needing parameters for your update in your trigger. In R:base you have the luxery of having all of the variables as global vars that would then be available to the trigger. When you are using Oterro, you don't have access to any of those variables. Is there a way to pass some parameters to a trigger for it to run.
My first thought of great use for a trigger would be to log updates to table. In R:base I have a var defined called vusername and then the trigger could fire when a table is updated to insert a record into another table using vusername and the date and time. When you are using Oterro, you don't have access to any variables. Troy Sosamon --------- Original Message ------------ Using the latest build of 6.5++ and Oterro, we are implementing triggers that are fired whether the insert, update, or delete originates from WiTango or R:Base application code. Suppose for example, you have an application where you are selling tickets. Purchasers can buy tickets either through an internet application or by calling the sales office and talking to a sales person who is running native R:Base to record the ticket sale. In either case you pick the ticket you want, and in Tango you hit submit or in R:Base you click Save or Ok, and the �booking� is inserted into the �booking� table. An after trigger insert fires and inserts the appropriate rows into the accounting ledger table. Later on, if you want to upgrade your tickets to premium seats, either on the internet or via the phone, again, upon updating the parent booking table, an after update trigger fires and the appropriate changes are made to the accounting ledger child table. Now, suppose you want to cancel your tickets, again, the trigger handles the billing upon update of the header table. Suppose the cancellation business logic is very complex such as assessing penalties depending upon how close to the event you cancel the tickets. All of this complex business logic can be coded into a single stored procedure and inserted into the sys_triggers table. Alternatively, you can have an R:Base programmer code the business logic into the R:Base application and a Tango programmer program the business logic into the internet application, and then, when the client changes the cancellation business logic, you need to implement the new logic in two application environments. With the business logic in �RMD� style code in the stored procedure, you can tweak the stored procedure, and both the R:Base LAN and the Tango internet applications will implement the new business logic without having to modify either. It is far more efficient to write a single instance of complicated code and have that code operate seamlessly and invisibly whether the insert/update/delete originates from a Tango app on the internet or an R:Base app via a LAN. Triggers provide a fastidious and clever mechanism to do this. Harlan ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
