C
Craig Alexander Morrison
No I did not I responded to Doug's Message.
Look down the copied messages....in that response.
Look down the copied messages....in that response.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
C
Craig Alexander Morrison
Yeah.
In DB2 Triggers are part of the database.
The application objects are
-User Defined Distinct Datatypes
-User Defined Structured Datatypes
-User Defined Functions
-Packages
-Stored Proceudures
-User Defined Methods
BTW are you implying from your responses that field and table validation
rules in Jet are part of the application?
In DB2 Triggers are part of the database.
The application objects are
-User Defined Distinct Datatypes
-User Defined Structured Datatypes
-User Defined Functions
-Packages
-Stored Proceudures
-User Defined Methods
BTW are you implying from your responses that field and table validation
rules in Jet are part of the application?
C
Craig Alexander Morrison
Well that explains it pefectly to me.
If you fail to see the relevance of that quote.
If you fail to see the relevance of that quote.
B
Brendan Reynolds
The way I see it, Terry, of course you are correct that triggers are not
part of DRI, but Craig is equally correct that they are enforced by the
DBMS. The key point, as I see it, is that if you attempt to manage the
updates using VBA code in an Access application, then the validation can not
be enforced if someone updates the data via another application. If you use
a trigger in a DBMS that supports them, then the validation will be enforced
regardless of the means used to update the data.
part of DRI, but Craig is equally correct that they are enforced by the
DBMS. The key point, as I see it, is that if you attempt to manage the
updates using VBA code in an Access application, then the validation can not
be enforced if someone updates the data via another application. If you use
a trigger in a DBMS that supports them, then the validation will be enforced
regardless of the means used to update the data.
C
Craig Alexander Morrison
or are you still confused?
You are certainly trying your best to do just that. (vbg)
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
news:%23YNL%[email protected]...
You are certainly trying your best to do just that. (vbg)
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
news:%23YNL%[email protected]...
C
Craig Alexander Morrison
My reasoning goes like this:-
From the above it is you who is confused.
Tables have to be coded, they are a developed item. Tables are created in
most SQL based DBMSs by a piece of SQL DDL.
Constraints are applied by SQL too.
Because you use graphical tools provided by the DBMS you have been protected
from the underlying SQL to generate the required structures and contraints.
If you use the DB2 command line processor which exposes this fact to you,
you can create a database and a table thus:
db2 => create database accdb2
db2 => connect to accdb2 user db2admin using db2admin
db2 => create table accounts(accountnum varchar(64) not null primary key,
firstname varchar(30) not null, lastname varchar(30) not null)
To put it another way tables have to be coded they are a developed item and
are part of the database rather than the application.
Do you mean DBMS or database here?
Do you mean database or DBMS here?
And although you did not see the relevance of the quote from Chris Date I
will quote from the other guy anyway.
"Rule 0. For any system that is advertised as, or claimed to be, a
relational database management system, that system must be able to manage
databases entirely through its relational capabilities." Ted Codd
(Computerworld, 14th-21st October 1985)
"Rule 10: Integrity constraints specific to a particular relational database
must be definable in a relational data sublanguage and storable in the
catalog, not in application programs." Ted Codd (Computerworld, 14th-21st
October 1985)
"Rule 12: If a relational system has a low-level (single-record-at-a-time)
language, that low level cannot be used to subvert or bypass the integrity
rules and contraints expressed in the higher level relational language
(multiple-records-at-a-time)." Ted Codd (Computerworld, 14th-21st October
1985)
DRI is easier to manage and setup but it is not really different from
Triggers/Triggered Actions.
Maintaining Data Integrity is the job of the DBMS and you use whatever
methods (preferably relational (or SQL(wg)) that the particular DBMS
supports, but it must be clear this is part of the job of the DBMS and not
the application.
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
news:[email protected]...
Stored procedures are not part of the inbuilt DRI of the database
Triggers are only a special sort of SPROC therefore they are not part of
the inbuilt DRI of the database.
To put it another way triggers have to be coded, they are a developed item
and are part of the application rather than the dbms.
From the above it is you who is confused.
Tables have to be coded, they are a developed item. Tables are created in
most SQL based DBMSs by a piece of SQL DDL.
Constraints are applied by SQL too.
Because you use graphical tools provided by the DBMS you have been protected
from the underlying SQL to generate the required structures and contraints.
If you use the DB2 command line processor which exposes this fact to you,
you can create a database and a table thus:
db2 => create database accdb2
db2 => connect to accdb2 user db2admin using db2admin
db2 => create table accounts(accountnum varchar(64) not null primary key,
firstname varchar(30) not null, lastname varchar(30) not null)
To put it another way triggers have to be coded, they are a developed item
and are part of the application rather than the dbms.
To put it another way tables have to be coded they are a developed item and
are part of the database rather than the application.
To put it another way triggers have to be coded, they are a developed item
and are part of the application rather than the dbms.
Do you mean DBMS or database here?
Triggers are only a special sort of SPROC therefore they are not part of
the inbuilt DRI of the database.
Do you mean database or DBMS here?
And although you did not see the relevance of the quote from Chris Date I
will quote from the other guy anyway.
"Rule 0. For any system that is advertised as, or claimed to be, a
relational database management system, that system must be able to manage
databases entirely through its relational capabilities." Ted Codd
(Computerworld, 14th-21st October 1985)
"Rule 10: Integrity constraints specific to a particular relational database
must be definable in a relational data sublanguage and storable in the
catalog, not in application programs." Ted Codd (Computerworld, 14th-21st
October 1985)
"Rule 12: If a relational system has a low-level (single-record-at-a-time)
language, that low level cannot be used to subvert or bypass the integrity
rules and contraints expressed in the higher level relational language
(multiple-records-at-a-time)." Ted Codd (Computerworld, 14th-21st October
1985)
DRI is easier to manage and setup but it is not really different from
Triggers/Triggered Actions.
Maintaining Data Integrity is the job of the DBMS and you use whatever
methods (preferably relational (or SQL(wg)) that the particular DBMS
supports, but it must be clear this is part of the job of the DBMS and not
the application.
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
news:[email protected]...
T
Terry Kreft
That it explains it perfectly to you explains it pefectly to me as well.
If you fail to see the irrelevancy of that quote.
If you fail to see the irrelevancy of that quote.
T
Terry Kreft
Look at the message tree.
Look at the sequence of postings.
There's not much hope of a structured discussion if you lose track of who
you are responding to.
--
Terry Kreft
Look at the sequence of postings.
There's not much hope of a structured discussion if you lose track of who
you are responding to.
--
Terry Kreft
Craig Alexander Morrison said:No I did not I responded to Doug's Message.
Look down the copied messages....in that response.
T
Terry Kreft
I find it fascinating how you are already presuming to tell me which
database tools I use.
You are quoting Codd when he is talking about RDBMS, almost by definition,
in that case, he is referring to a normalised database. We are discussing a
non-normalised database, if we aren't discussing a non-normalised database
then there is no "redundant data" to cascade.
If you can't see the difference between creating a table in a database and
creating a trigger then there really is no point in continuing this
discussion.
database tools I use.
You are quoting Codd when he is talking about RDBMS, almost by definition,
in that case, he is referring to a normalised database. We are discussing a
non-normalised database, if we aren't discussing a non-normalised database
then there is no "redundant data" to cascade.
If you can't see the difference between creating a table in a database and
creating a trigger then there really is no point in continuing this
discussion.
T
Terry Kreft
Are triggers DDL or DML?
--
Terry Kreft
--
Terry Kreft
Craig Alexander Morrison said:Yeah.
In DB2 Triggers are part of the database.
The application objects are
-User Defined Distinct Datatypes
-User Defined Structured Datatypes
-User Defined Functions
-Packages
-Stored Proceudures
-User Defined Methods
BTW are you implying from your responses that field and table validation
rules in Jet are part of the application?
--
Slainte
Craig Alexander Morrison
Crawbridge Data (Scotland) Limited
T
Terry Kreft
Brendan,
But triggers are DML not DDL. Therefore IMO are part of the application not
the database.
The way I look at it is this, you start off with the scope of your database,
from that you define your entities and relations (you normalise).
You are then pretty much able to create the db except, for reasons of
(normally) performance you may denormalise.
You then look at implementing triggers in order to enforce DRI for the
denormalised data.
Triggers are used for application level reasons.
But triggers are DML not DDL. Therefore IMO are part of the application not
the database.
The way I look at it is this, you start off with the scope of your database,
from that you define your entities and relations (you normalise).
You are then pretty much able to create the db except, for reasons of
(normally) performance you may denormalise.
You then look at implementing triggers in order to enforce DRI for the
denormalised data.
Triggers are used for application level reasons.
C
Craig Alexander Morrison
You are quoting Codd when he is talking about RDBMS, almost by definition,
I think you had better revisit Codd if that's what you think he said.
.....read the quote from Date which explains it to you.
However you are right there is little point continuing this...
in that case, he is referring to a normalised database. We are discussing
a
non-normalised database, if we aren't discussing a non-normalised database
then there is no "redundant data" to cascade.
I think you had better revisit Codd if that's what you think he said.
.....read the quote from Date which explains it to you.
However you are right there is little point continuing this...
M
Michael Gramelspacher
Please allow me a question to see if I am following this conversation.Brendan,
But triggers are DML not DDL. Therefore IMO are part of the application not
the database.
The way I look at it is this, you start off with the scope of your database,
from that you define your entities and relations (you normalise).
You are then pretty much able to create the db except, for reasons of
(normally) performance you may denormalise.
You then look at implementing triggers in order to enforce DRI for the
denormalised data.
Triggers are used for application level reasons.
If a user were to type a duplicate row into a DB2 or SQL Server table,
assuming a user were allowed to do that, would my stored procedure run
to prevent this? Is this even a yes or no question?
T
Terry Kreft
You want me to read the quote from Date which was irrelevant to the post you
answered with it, that would be just an exercise in futility.
It appears that you are failing to see the difference between DDL and DML,
or the fact that once you start to use DML then you are moving into the
region of the application.
Anyway, I think I'll call it quits on this thread
answered with it, that would be just an exercise in futility.
It appears that you are failing to see the difference between DDL and DML,
or the fact that once you start to use DML then you are moving into the
region of the application.
Anyway, I think I'll call it quits on this thread
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.