Discussion :

[alicia26]

Je vois, il ne me reste plus qu'à faire ce qui suit:

Cela est certainement dû à certaines données corrompues de votre table.
Essayez de faire la même chose par lots plus petits pour voir.
Code :
INSERT INTO ..
SELECT TOP XXX FROM TABLE ORDER BY <colonne>

Je ne peux pas trop me plaindre, j'ai déjà copié correctement 142 tables sur 143.
A propos, j'ai trouvé cette requête qui permet d'avoir la taille et le nombre de lignes d'une table.

Code :

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

1
2
3
 
USE pubs
EXEC sp_spaceused 'titles'

Une idée d'une seule requête pour m'afficher toutes les tables de ma base, elle serait plus pratique....

[SQLpro]

Les données ne sont pas exacte si vous n'avez pas fait un DBCC UPDATEUSAGE avant.
Pour toutes les tables il faut taper dans la table sysindexes. Elles contient les points d'entrée de tous les index y compris les tables.

A +

[dbaffaleuf]

Il faut aussi penser à passer la base en single_user d'abord avant de faire le repair:

Code :

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

1
2
ALTER DATABASE IN_ERICSS set SINGLE_USER
DBCC CHECKDB('IN_ERICSS','REPAIR_ALLOW_DATA_LOSS')

et relancer un DBCC CHECKDB derrière pour confirmer que toutes les erreurs ont été réparées:

Code :

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

DBCC CHECKDB('IN_ERICSS','REPAIR_ALLOW_DATA_LOSS')

REPAIR_ALLOW_DATA_LOSS ne répare pas tout, quoiqu'un ID de page à 0:0, ça devrait marcher, par contre il va sûrement désallouer les pages en question.

Le problème à l'origine peut être lié à une défaillance du matériel, jetez un coup d'oeil au journal d'évènements système sur les machines impliquées dans le transfert. Il y a peut être un driver qui crache des messages d'erreurs depuis un certain temps.

David B.