| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
Hi,
< This note is also placed in the rally competion file >
I am right now teaching a course in Cobol and Rdb used from a
Smartstar environment, and after discussing some details with the
danish SMARTSTAR support person something VERY interesting came up.
He said:
> If severel relations are shown on the screen (form/report) then
> each relation is updated within seperate binds to the database.
> ie. First everything is shown using ONE read_only transaction,
> then when updating the screen-information, records related
> to separate relations are updated in separate binds.
THIS MUST MEAN TROUBLE!!!!
1) The number of binds could be enormous (far more than Rally ever should
be able to use), meaning one h... of memory use.
2) and even worse...
There is NO INTEGRITY SECURITY. Ie. One of the relations might be
updated and the rest not.
3) NO new features of rdb using somekind of two-phase commit or anything like,
could repair these problems.
If this is all correct, then it must be a great possibillty to knock out
SMARTSTAR in favour of RALLY.
If not please let me know.
Lars Brunsgaard
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 76.1 | Terminology Problem | AUNTB::BOOTH | A career of MISunderstanding | Fri Feb 26 1988 16:08 | 23 |
Hi,
< this reply is also placed in the rally competition file>
In SMARTSTAR terminology a "bind" in this case refers to variable
activity between a 3GL and SMARTSTAR.
What we call a database bind, they refer to as opening the database.
Consequently, what you have in your scenario is a case where multiple
3GL "binds" may occur, depending on how the code is written, within
one session of an opened database (i.e. one transaction). When the
screen displays, the database is "opened" (the Rdb bind occurs).
That session doesn't end until the screen activity has ceased.
So, what we have is a case where terminology is not equivalent,
but neither are there the problems mentioned in the base note. Since
all the activity is handled in one transaction, all of the Rdb
integrity features are intact (constraints, locking, etc.). There is
no huge memory overhead, and if there is a system problem, the
incomplete transactions can be rolled back.
---- Michael Booth
| |||||