|
i have a table Companiesdata CREATE TABLE [dbo].[Companiesdata] ( [Company Name] nvarchar(255), [Industry] varchar(40), [ParentId] int NULL, ) the records are i have other table create table dbo.companycategories ( categoryID int identity(1,1), Industry varchar(40) ) Now i want a procedure to automatically insert data into companycategories table if i inserted in companiesdata table. i.e my output should be If i insert into companiesdata values ('ijk technologies','finance',4) then the industry field should automatically get inserted into companycategories table select * from companycategories CategoryID Industry
(comments are locked)
|
|
You can use AFTER INSERT TRIGGER. See CREATE TRIGGER (Transact-SQL) on MSDN. hey pavel thankyou .. will check it out ..
Aug 06 '12 at 05:08 AM
tsaliki
(comments are locked)
|
|
Instead of the trigger solution I would recommend you create a stored procedure that inserts CompaniesData and CompanyCategories at the same time. All inserts to CompaniesData should be through this stored procedure. scot i didnt get u.can u please write a store procedure for the above one ?
Aug 06 '12 at 05:33 AM
tsaliki
Although we do the same for some databases, but Triggers tends to be the safest approach to handle cases like manual INSERT etc.
Aug 06 '12 at 09:59 AM
Usman Butt
Yes creating triggers tends to be fastest than stored procedures
Aug 06 '12 at 10:43 AM
sravan.434
Sorry but I would disagree a bit. They can be fastest on some occasions but not always. Triggers are generally called evil because of the additional problems it can cause which can also include performance issues.
Aug 06 '12 at 11:07 AM
Usman Butt
As mentioned it depends how the db is used and accessed. Triggers are for sure the safest way, if users (developers) have dirrect access to the uderlying tables as in that scenario TRIGGERS will solve every possible way of inserts/updates. On the other way, if access to the underlying tables is limited and possible only using the views, functions and stored procedures then with proper procedures and security design, it will sever the same way as TRIGGERS and the insets/updates of other tables can be optimized based on the operations done by the stored procs.
Aug 06 '12 at 11:38 AM
Pavel Pawlowski
(comments are locked)
|

