TRIGGER copia tabella poi cancella dati

mercoledì 19 maggio 2010 - 17.47

anj Profilo | Newbie

Salve a tutti.
Premetto che è il primo trigger che faccio.
devo realizzare un TRIGGER che deve copiare una tabella in un'altra, poi deve cancellare i dati copiati dalla vecchia tabella.
Spero abbiate capito.

Ho iniziato così:
CREATE TRIGGER [dbo].[CDC_SCARICAECONV] ON [dbo].[CDC1] FOR INSERT AS BEGIN -- copia dei dati da CDC1 a CDC insert into CDC (giorno, prova) select distinct cast(dbo.convertiData(giorno) as smalldatetime), prova from CDC1 END

la funzione dbo.convertiData mi permette di convertire alcuni dati ricevuti da un formato a un altro..


Potete aiutarmi??

Grazie in anticipo.

ma_di Profilo | Junior Member

Ciao.
Ricordo il tuo problema...
Già dato un'occhiata qui?
http://msdn.microsoft.com/en-us/library/aa258254(SQL.80).aspx

Ciao.

ps... sono un po' contrario al codice prêt à porter...
Se poi proprio non ce la fai....

ciccio_ska Profilo | Newbie

Ciao,
se devi copiare i dati da una tabella in un'altra io farei una query di insert o una stored, e poi un trigger sulla tabella in cui vai ad inserire i dati che elimina lo stesso da quella precedente.
In Sql Server è possibile usare due "tabelle" di sistema chiamate Inserted e Deleted :
Inserted -> contiene il record appena inserito
Deleted -> contiene il record appena eliminato

Prova così tienimi informato.
Ciao


Francesco Scalise
blog: http://www.flash-hacks.com

alx_81 Profilo | Guru

>Salve a tutti.
Ciao

>Premetto che è il primo trigger che faccio.
>devo realizzare un TRIGGER che deve copiare una tabella in un'altra,
>poi deve cancellare i dati copiati dalla vecchia tabella.
se puoi, fai una stored procedure che fa tutto. Creando una apposita transazione, evitando il trigger. Questo è il mio spassionato consiglio, perchè il trigger, già di suo non molto visibile in futuro (pensa anche a chi dovrà o potrà lavorare con te), potrebbe non essere la soluzione migliore. Considera che poi OGNI insert lancia quel trigger. Se è solo quello il punto, può andare, ma se in futuro dovessi inserire con altre metodologie che non vogliono la duplicazione/cancellazione dei dati?
Ti dico, fai attenzione, secondo me la scelta di un trigger va fatta in maniera ponderata.
Una bella stored procedure che in se include la logica del trigger invece la trovo più manutenibile e parlante..

>Grazie in anticipo.
di nulla!
--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

anj Profilo | Newbie

>Ciao,
>se devi copiare i dati da una tabella in un'altra io farei una
>query di insert o una stored, e poi un trigger sulla tabella
>in cui vai ad inserire i dati che elimina lo stesso da quella
>precedente.
>In Sql Server è possibile usare due "tabelle" di sistema chiamate
>Inserted e Deleted :
>Inserted -> contiene il record appena inserito
>Deleted -> contiene il record appena eliminato
>
>Prova così tienimi informato.
>Ciao
>

>
>Francesco Scalise
>blog: http://www.flash-hacks.com



Ciao
Ho usato il TRIGGER perchè deve riversare i dati in automatico da una tabella a un altra, grazie al trigger me lo fa senza che chieda l'invio della query.
Il problema è che mentre riversa deve fare la conversione da "nvarchar" a "smalldatetime" (ti prego non dire che c'è uno spreco di memoria ecc .. Non dipende da me, è un sistema in automatico che preleva i dati e li spedisce direttamente al sw che utilizzo), non posso modificare o cambiare i dati se non quando saranno dentro il DB MSSQL.

grazie

anj Profilo | Newbie

>>Salve a tutti.
>Ciao
>
>>Premetto che è il primo trigger che faccio.
>>devo realizzare un TRIGGER che deve copiare una tabella in un'altra,
>>poi deve cancellare i dati copiati dalla vecchia tabella.
>se puoi, fai una stored procedure che fa tutto. Creando una apposita
>transazione, evitando il trigger. Questo è il mio spassionato
>consiglio, perchè il trigger, già di suo non molto visibile in
>futuro (pensa anche a chi dovrà o potrà lavorare con te), potrebbe
>non essere la soluzione migliore. Considera che poi OGNI insert
>lancia quel trigger. Se è solo quello il punto, può andare, ma
>se in futuro dovessi inserire con altre metodologie che non vogliono
>la duplicazione/cancellazione dei dati?
>Ti dico, fai attenzione, secondo me la scelta di un trigger va
>fatta in maniera ponderata.
>Una bella stored procedure che in se include la logica del trigger
>invece la trovo più manutenibile e parlante..
>
>>Grazie in anticipo.
>di nulla!
>--
>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://www.alessandroalpi.net
>http://blogs.dotnethell.it/suxstellino
>http://mvp.support.microsoft.com/profile/Alessandro.Alpi
>


Perdonami ma sono agli inizi del MSSQL,
le stored procedure possono essere attivate in automatico?
quando la prima tabella riceve i dati in automatico gli stessi dati devono essere trasmessi alla secondo?

ma_di Profilo | Junior Member

Per provare:
Tabella CDC ( ipoteticamente quella che riceve i dati ) definita come:
GIORNO nvarchar(10)
PROVA nvarchar(10)

Tabella CDC1 (ipoteticamente quella "di lavoro")
DATA smalldatetime
PROVA nvarchar(10)

USE [WFL] -- sostituire con il nome del database di lavoro
GO
/****** Object: Trigger [dbo].[CDCSCARICAECONV] Script Date: 05/19/2010 22:18:04 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE TRIGGER [dbo].[CDCSCARICAECONV]
ON [dbo].[CDC1] FOR INSERT
AS
BEGIN
SET NOCOUNT ON;
DECLARE @GIORNO AS NVARCHAR(10) -- variabile per il giorno inserito in CDC1
DECLARE @PROVA AS NVARCHAR(10) -- variabile per altri usi
DECLARE @NEW_GIORNO AS SMALLDATETIME -- variabile per giorno su CDC

SELECT @GIORNO=GIORNO FROM INSERTED
SELECT @PROVA=PROVA FROM INSERTED

-- deleted and inserted are logical (conceptual) tables. They are structurally similar
-- to the table on which the trigger is defined, that is, the table on which the user
-- action is attempted, and hold the old values or new values of the rows
-- that may be changed by the user action....

SET @NEW_GIORNO=CONVERT(SMALLDATETIME, @GIORNO)

INSERT INTO CDC
VALUES (@NEW_GIORNO,@PROVA)

DELETE FROM CDC1 WHERE GIORNO=@GIORNO
-- OPPURE TRUNCATE TABLE CDC1

END

Inserisci giorno e prova in CDC1 e poi apri CDC; dovresti vedere i dati copiati; prova a riaprire CDC1 e non dovresti più trovare niente.
ATTENZIONE : il giorno deve essere inserito come aaaa-mm-gg

L'ho scritta alla veloce...è per darti un'idea.
Ciao
http://msdn.microsoft.com/en-us/library/aa258254


anj Profilo | Newbie

>Per provare:
>Tabella CDC ( ipoteticamente quella che riceve i dati ) definita
>come:
>GIORNO nvarchar(10)
>PROVA nvarchar(10)
>
>Tabella CDC1 (ipoteticamente quella "di lavoro")
>DATA smalldatetime
>PROVA nvarchar(10)
>
>USE [WFL] -- sostituire con il nome del database di lavoro
>GO
>/****** Object: Trigger [dbo].[CDCSCARICAECONV] Script Date:
>05/19/2010 22:18:04 ******/
>SET ANSI_NULLS ON
>GO
>SET QUOTED_IDENTIFIER ON
>GO
>
>CREATE TRIGGER [dbo].[CDCSCARICAECONV]
> ON [dbo].[CDC1] FOR INSERT
>AS
>BEGIN
> SET NOCOUNT ON;
> DECLARE @GIORNO AS NVARCHAR(10) -- variabile per il giorno
>inserito in CDC1
> DECLARE @PROVA AS NVARCHAR(10) -- variabile per altri usi
> DECLARE @NEW_GIORNO AS SMALLDATETIME -- variabile per giorno
>su CDC
>
> SELECT @GIORNO=GIORNO FROM INSERTED
> SELECT @PROVA=PROVA FROM INSERTED
>
>-- deleted and inserted are logical (conceptual) tables. They
>are structurally similar
>-- to the table on which the trigger is defined, that is, the
>table on which the user
>-- action is attempted, and hold the old values or new values
>of the rows
>-- that may be changed by the user action....
>
> SET @NEW_GIORNO=CONVERT(SMALLDATETIME, @GIORNO)
>
> INSERT INTO CDC
> VALUES (@NEW_GIORNO,@PROVA)
>
> DELETE FROM CDC1 WHERE GIORNO=@GIORNO
> -- OPPURE TRUNCATE TABLE CDC1
>
>END
>
>Inserisci giorno e prova in CDC1 e poi apri CDC; dovresti vedere
>i dati copiati; prova a riaprire CDC1 e non dovresti più trovare
>niente.
>ATTENZIONE : il giorno deve essere inserito come aaaa-mm-gg
>
>L'ho scritta alla veloce...è per darti un'idea.
>Ciao
>http://msdn.microsoft.com/en-us/library/aa258254
>
>
>


Fantastico!

ti ringrazio, lo provo e ti faccio sapere.

Per ora.. 10!!

alx_81 Profilo | Guru

>Perdonami ma sono agli inizi del MSSQL,
>le stored procedure possono essere attivate in automatico?
>quando la prima tabella riceve i dati in automatico gli stessi
>dati devono essere trasmessi alla secondo?
se non hai controllo sulla procedura di inserimento, la stored procedure non fa al caso tuo
--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

anj Profilo | Newbie

>>Perdonami ma sono agli inizi del MSSQL,
>>le stored procedure possono essere attivate in automatico?
>>quando la prima tabella riceve i dati in automatico gli stessi
>>dati devono essere trasmessi alla secondo?
>se non hai controllo sulla procedura di inserimento, la stored
>procedure non fa al caso tuo
>--
>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://www.alessandroalpi.net
>http://blogs.dotnethell.it/suxstellino
>http://mvp.support.microsoft.com/profile/Alessandro.Alpi
>

Immaginavo...

anj Profilo | Newbie

RISOLTO: Ti ringrazio
usando la tua funzione mi eliminava "ore/minuti/secondi"..

quindi ho utilizzato il trigger che avevo fatto unendo la funzione di conversione, in più o preso dal tuo trigger la

TRUNCATE TABLE..

Ottimo Tante grazie.
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5