The PSQL language extensions include the following language elements:
Restrictions on PSQL
Certain language restrictions apply to the code in PSQL modules:
Statement Types Not Supported in PSQL
The following statement types are not supported in triggers or stored procedures:
Exception handlers can be written to “swallow” an error by dealing with it in some way. For example, an input row in an iterative routine that causes an exception does not need to cause the entire process to stop. The exception handling inside the trigger or procedure can allow the problem input to be skipped—perhaps logging the error in a text file or error table —and let further processing continue.
The code module can handle an error itself with an optional piece of code, known as an exception block, which is a sequence of statements bounded by BEGIN and END, preceded by a directive beginning with the keyword WHEN.
An unhandled exception stops processing, undoes any work done thus far, and returns an error message to the application. You can also have your code raise a custom exception itself and stop processing. You can handle the error in your code—or stop the processing and return a custom message to the client application. If the code module is a trigger, the DML operation in which the error occurred will be undone also. You can create as many custom exceptions as you need in a database. From v.1.5 on, you can use runtime data and construct extensions to your exception messages “on the fly.”
Firebird events are optional “signals” that PSQL modules can accumulate during execution, to be passed to client applications once the work has been committed. Client applications anywhere on the network can optionally listen—by way of “event alerters”—for specific events that they are interested in, without needing to poll for changes specifically.
Procedures and triggers can be granted privileges for specific actions (SELECT, INSERT, DELETE, and so on) on tables, just as users or roles can be granted privileges. There is no special syntax: An ordinary GRANT statement is used, but the recipient named in the TO clause is a trigger or procedure, instead of a user or a role. Similarly, privileges can be revoked from procedures and triggers.
It is not always necessary to grant privileges to trigger and procedure modules. It is enough for either the user or the module to have the privileges for the actions the module has to perform.
For example, if a user performs an UPDATE of table A, which fires a trigger, and the trigger performs an INSERT on table B, the action is allowed if the user has INSERT privileges on the table or the trigger has INSERT privileges on the table.
If there are not sufficient privileges for a trigger or procedure to perform its actions, Firebird fires an SQL error and sets the appropriate error code number. You can intercept this error code with an exception handler, just as with other exceptions.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.