Discussion :

[manas]

Bonjour ,
J'aimerai transférer des données d'une table de "travail" vers une table identique "backup" sur base de temps . Une à 8H00,16H00,et 00H00.
Quelqu'un pourrait il me mettre sur la bonne voie . Trigger ou autre ? Merci.

[nabilfaouzi]

Est ce que tu veux dire une tache planifié qui va alimenter dans des tranches horaires la table back up?
si c'est le cas tu peux crée un nouveau job et le faire exécuter en tant que tache planifié en exécutant la requête ou la procédure suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[tablebackup ]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[tablebackup ]
select * into tablebackup from table

j'espère que ça vous aidera

[manas]

J'ai créer un jobs à 8 12 et 00 HH .
J'aimerai par exemple prendre pour le job de 8H00 tout les records de la table travail dont l'horodatage est inférieur à 6H00 et les insérer dans la table backup sans avoir de doublons.

[SQLpro]

Beaucoup plus rapide serait de vider la table et de faire une capture binaire des données, puis réinjection.
1) TRUNCATE TABLE ... (base de destination)
2) export avec bcp.exe out en format natif de la table en question
3) import avec bcp.exe in du fichier créé en 2)

bcp.exe est l'utilitaire en ligne de commande d'import / export de SQL Server.

A +

[Invité]

1) TRUNCATE TABLE ... (base de destination)

Ça permettrait aussi de conserver les éventuelles indexes, stats et contraintes qu'un radical drop table.

[manas]

Je ne gère pas la table travail (je ne peux pas faire de suppression)
J'ai créer un jobs à 8 12 et 00 HH .
J'aimerai par exemple prendre pour le job de 8H00 tout les records de la table travail dont l'horodatage est inférieur à 6H00 et les insérer dans la table backup sans avoir

[zinzineti]

Attention aux colonnes auto-incrément (IDENTITY) si elles existent !

[Invité]

Attention aux colonnes auto-incrément (IDENTITY) si elles existent !

Que veux-tu dire, je ne vois pas le problème ?

[elsuket]

Si la table d'archive contient elle aussi une table dont la colonne a la propriété de compteur auto-incrémenté, l'INSERT dans la d'archive ne marchera pas.
Deux solutions :

- ne pas spécifier la colonne dans le SELECT, très simple
- spécifier SET IDENTITY_INSERT maTable ON avant l'INSERT, puis SET IDENTITY_INSERT maTable OFF après l'INSERT, mais je trouve ça moche

@++

[Invité]

Si la table d'archive contient elle aussi une table dont la colonne a la propriété de compteur auto-incrémenté, l'INSERT dans la d'archive ne marchera pas.
Deux solutions :

- ne pas spécifier la colonne dans le SELECT, très simple
- spécifier SET IDENTITY_INSERT maTable ON avant l'INSERT, puis SET IDENTITY_INSERT maTable OFF après l'INSERT, mais je trouve ça moche

Ok, je comprends le point
Mais comme il faisait un drop table puis un select * into ... la colonne dans la table de destination n'est plus auto-incrémentée dans ce cas.
Mais bon, il vaut mieux être prudent, vous avez raison sur ce point.

[Ptit_Dje]

Vous pouvez aussi penser à utiliser l'operateur switch.

Générez une partition vide a votre table de destination dans laquelle vous switchez votre table de travail et ensuite vous re-effectuer un merge de la partition et du reste de la table et ca pousse vos donnéees très rapidement.

[mikedavem]

On ne connait pas ici la volumétrie associée à votre table de travail et celle d'historique. L'activité est-elle fortement transactionnelle sur cette table ? etc ...

Il y a en effet beaucoup de solutions à votre problème. Maintenant il faut choisir celle qui correspondra à votre besoin. Pas besoin de sortir l'artillerie lourde si cela n'est pas nécessaire.

++