Dear Subbu,
The first time I was confronted with the issue you describe, I was astonished by this inconsistency. Some people told me that it was not possible to enforce the integrity of the database. At least not for every field. Meanwhile I learned it is quite easy to ensure that the referential integrity of the database is maintained. It takes however a lot of work to do it for all lacking relationships. In case of payment terms it is just a matter of adding the VendTable to the node DeleteActions of the table PaymTerm and then set the property DeleteAction to restricted. As a result one can not delete records in the PaymTerm table as long as the data is present in the VendTable. Now what is it all about! Is it a matter of design or is there a reason for this design. Referential integrity is concerned with keeping the relationships between tables synchronized. The primary objective of referential integrity is to prevent 'orphans;' i.e., records in the child table that cannot be related to a record in the parent table. There are two methods to enforce referential integrity: constraints and triggers. Constraints fall in the group of Declarative Referential Integrity (DRI), where rules are declared as part of the table's schema. FOREIGN KEY constraints identify the relationships between tables. Triggers fall in the group of Procedural Referential Integrity, where rules are checked in procedural code. A trigger is a special type of stored procedure that automatically takes effect when the data in a specified table is modified. A trigger is invoked in response to an INSERT, UPDATE, or DELETE statement. "Declarative referential integrity should be used for strict relational database implementation." However there are times such a strict implementaion may be inhibiting. When the database structure is changing rapidly it will increase the amount of work. Before one can drop a table from the database all constraints have to be removed. Imagine what needs to be done for dropping a lot of tables! I do not know whether perhaps the functionality of configuration keys is the reason for using triggers instead of constraints. It might be! Tables are created and dropped depending on configuration keys selected. Another reason might be related to the version of SQL Server available when development of Axapta started. DRI is supported from release 6.0. In earlier versions versions DRI was not supported in the Data Definition Language (DDL ) syntax. DDL is used to communicate with the database (SQL Server or Oracle). It is a matter of design. Referential integrity, an important part of an entity relationship model, is not embedded in the system. At least one would expect that if a relation is defined between two tables, either directly on the table or through the relation on the extended data type of a key field, the integrity is safeguarded. Well now that is not the case! But we still have the DeleteActions to overcome the problem. I agree it is a lot of work to set it up for all the lacking relationships. Regards Danny Gaethofs --- In [EMAIL PROTECTED], "Subbu" <[EMAIL PROTECTED]> wrote: > > > Ax3.0 with SP3: > > Hi, > I have created a new vendor and attached payment terms to 'A'. > I went to the table and deleted record 'A'. Now, I came to the > vendor which I just created and found still its using payment > terms 'A' even though its deleted at the table level. > > I have two questions. > > 1. Do you think if it is allowed to delete a record when its in use? > is it not violating the RDMS concept against the data integrity? > > > 2. Its still showing up the 'A'. I cleared the user cache, but still > its showing 'A' for the vendor. > > I am just wondering if you accept this issue with me. > > > Any ideas are greatly appreciated!. > Is Axapta going to screw my Implemetation ( Largest in USA )? I > don't want to support this type of systems!. > > Thanks, > Subbu ------------------------ Yahoo! Groups Sponsor --------------------~--> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar. Now with Pop-Up Blocker. Get it for free! http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/kGEolB/TM --------------------------------------------------------------------~-> Sharing the knowledge on Axapta. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Axapta-Knowledge-Village/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
