I HELP YOU, YOU HELP
ME. THEORY OF SUCCESS.......
FREQUENTLY ASKED INTERVIEW QUESTIONS OF DATABASE OR PROGRESS IN VARIOUS COMPANY. YOU JUST READ ALL THESE QUESTIONS, THEY HELP IN SUCCESS OR YOUR CARRIER
DOWNLOAD PROGRESS , DATABASE, PROGRESS 10.B INTERVIEW QUESTIONS.
FREQUENTLY ASKED INTERVIEW QUESTIONS OF DATABASE OR PROGRESS IN VARIOUS COMPANY. YOU JUST READ ALL THESE QUESTIONS, THEY HELP IN SUCCESS OR YOUR CARRIER
DOWNLOAD PROGRESS , DATABASE, PROGRESS 10.B INTERVIEW QUESTIONS.
Static and Dynamic
Temp Tables:-
static temp–table is
created with the DEFINE TEMP–TABLE statement and configured at
compile time. A
dynamic temp–table is created with the CREATE TEMP–TABLE statement
which creates a
dynamic handle to a temp–table object whose fields and buffers are configured
at runtime. It is
possible to associate a dynamic BUFFER object with a static temp–table which
allows a certain
amount of runtime manipulation. It is also possible to associate a temp–table
object with a static
temp–table as follows:
DEFINE VARIABLE tth
AS WIDGET-HANDLE.
DEFINE TEMP-TABLE
tmptblx LIKE customer.
tth =
tmptblx:HANDLE.
Adding Fields to the
Dynamic Temp–table:
Once you have
created the empty temp–table object, you must add fields to it to make it
useful.
There are four
methods you can use to add fields to the temp–table:
• CREATE–LIKE( ) —
copies the field definitions from a source table and establishes all
the indexes of the
source table unless specified otherwise.
• ADD–FIELDS–FROM( )
— copies the specified fields from a source table. No indexes
are established.
This method can be used multiple times on the same temp–table and is
especially useful
when the rows of the temp–table need to represent a join.
• ADD–LIKE–FIELD( )
— copies the single field specified from a source table.
• ADD–NEW–FIELD( ) —
adds a field with the specified properties.
Adding Indexes to
the Dynamic Temp–table:-
ADD–INDEX–FIELD( )
—ADD–LIKE–INDEX( ) —ADD–NEW–INDEX( )
Completing the
Dynamic Temp–table:-
DEFINE VARIABLE
tthandle AS HANDLE.
CREATE TEMP-TABLE
tthandle.
tthandle:CREATE-LIKE("customer").
tthandle:ADD-FIELDS-FROM("salesrep","month-quota").
tthandle:ADD-NEW-FIELD("f1","integer").
/* add an index like
the salesrep.sales-rep index and call it "srep" */
tthandle:ADD-LIKE-INDEX("srep","sales-rep","salesrep").
/* the definition of
temp-table, "newcust", is complete */
tthandle:TEMP-TABLE-PREPARE("newcust").
Triggers:-
A database trigger
is a block of 4GL code that executes whenever a specific database event occurs.
A database event is an action performed against a database. For example, when
you
write a record to a
database, a WRITE event occurs. Because database triggers execute whenever a
database event occurs, they are useful for tasks such as referential integrity.
For example, if you delete a customer record from a database, you may also want
to delete all of the customer’s order records.
Progress supports
two types of database triggers: schema and session. A schema trigger is a .p
procedure that you
add, through the Data Dictionary, to the schema of a database. A session
trigger is a section
of code that you add to a larger, enclosing procedure.
Differences
Between Schema and Session Triggers:-
Although their
syntax is slightly different, schema and session triggers provide similar
functionality. The
important difference between them is that schema triggers are independent
procedures; whereas
session triggers are contained within a larger procedure. Because of this
difference, schema
triggers always execute when a specified event occurs, regardless of what
application
initiates the event. Session triggers are defined as part of an application and
are only in effect for that application.
Since session
triggers are executed from within an enclosing procedure, they have access to
the frames, widgets, and variables defined in the enclosing procedure. Since
schema triggers are compiled separately from the procedure that initiates their
execution, they do not have access to the procedure’s frames, widgets, and
variables.
RAW-TRANSFER
Statement:--- The RAW-TRANSFER statement allows you to transfer a record from a
RAW field to a buffer, or from a buffer to a RAW field. You can also transfer
directly from buffer to buffer
Collision
Manager:-- The collision manager (on the right side in Figure 11–2)
represents a central area where all data collisions in the database network
would be resolved. The collision manager could be located on a separate machine.
The results of data collision resolution could be transferred to the master
database, then propagated to all other sites
Session Triggers:-
You define a database session trigger within a Progress procedure. The trigger
persists while the procedure that defined it and any subprocedures are running.
A session trigger takes effect when Progress encounters it at run time. It
remains in effect until the defining procedure terminates. However, if a
subprocedure contains another trigger for the same table/event or field/event
pair, the trigger in the subprocedure overrides the original trigger. After the
subprocedure returns, the original trigger goes back into
effect.
Record Bleeding:-
A bleeding record lock occurs when a buffer with NO–LOCK inherits a
SHARE–LOCK from another buffer during a record disconnect.
DEFINE BUFFER acust
FOR customer. DEFINE BUFFER bcust FOR customer.
FIND acust WHERE
acust.cust-num = 1 NO-LOCK.
FIND bcust WHERE
bcust.cust-num = 1 SHARE-LOCK.
RELEASE
bcust.
When the second FIND
statement executes, the NO–LOCK state of acust is upgraded to SHARE–LOCK. When
Progress executes the RELEASE statement, the customer record is disconnected
from the bcust buffer and its SHARE–LOCK is downgraded to a NO–LOCK. What
happens to the acust buffer lock status? If acust retains the SHARE–LOCK, then
you can say that the bcust lock bled to acust. This is a bleeding record
lock.
Managing Locks to
Improve Concurrency:-
• Eliminate “deadly
embrace”
• Decrease the scope
of transactions
• Prevent users from
tying up records for extended periods of time
Each time you want
to present data to the user for inspection and possible update, follow this
procedure:
1. Request and
display the record with the NO–LOCK option.
2. Let the user
manipulate the data until the user signals that they have finished (ON LEAVE
OF field, ON CHOOSE
OF ok–button, or similar).
3. Request the same
record again using the FIND CURRENT or GET CURRENT statement
with the
EXCLUSIVE–LOCK option.
4. Use the
CURRENT–CHANGED function to see if the original record has changed since
you first presented
it to the user.
5. If the record is
the same, commit the change.
6. If the record has
changed, inform the user, display the new data, and repeat the
process.
DOWNLOAD PROGRESS QUESTIONS FROM BELOW LINK'S
IF YOU FIND ANY ANSWER WRONG,COMMENT ME, SO THAT I RIGHT
THAT ANSWER
0 comments:
Post a Comment