Discussion :

[msomso]

Bonjour
Lors de nos tests, nous avons besoin de supprimer l'ensemble des tables d'une base (schéma dbo) avec des contraintes d'intégrités.
Est-il possible de forcer cette suppression en masse sans tenir compte de l'ordre des contraintes ?

Je rencontre des problèmes (plantage session) lors de la suppression manuelle des contraintes.

Merci de votre aide
msomso

PS
Avec Oracle, la méthode consiste à supprimer le compte et le recréer, mais avec dbo, je crois que ce n'est pas possible ....

[Fabien Celaia]

Soit vous suivez l'ordre des contraintes
Soit vous jouez voter script de drop tables en boucle tant qu'il y a des tables
Soit vous générez avant tout un script de suppression de toutes les IR, ce qui est le plus élégant.

Il y a aussi l'option déconseillée de flinguer les RI directement via les tables système.

[msomso]

Bonjour,

le problème est que, sans parler du script que je ferais volontiers, je n'arrive pas à supprimer certaines contraintes manuellement: ma session reste bloquée.
Pour certaines tables, l'ordre "drop table" fait planter la session sans aucun message d'erreur et sans qu'il n'y ait aucune contrainte FK référençant cette table dans sysconstraints.

J'ai trouvé un message d'erreur dans le log du serveur :

server Failed to allocate memory for column level datachange counters for database 'xxx' (5), object 'yyy' (12425365zz), data partition 'yyy_1242536529' (12425365zz). Column level datachange counters will not be tracked. Increase the config parameter 'procedure cache size' to allocate more memory.

J'ai augmenté alors le paramètre indiqué ci-dessus, mais le problème a continué. Et curieusement, il semblerait que seulement la suppression des index a permit de supprimer les tables restantes (action entreprise par mon collègue).

Quelqu'un aurait rencontré/résolu ce problème ?

-------------------------------------------------------
J'en profite pour poser quelque questions concernant les procédures sp_primarykey, sp_foreignkey et sp_dropkey. La documentation est un peu confuse à ce sujet (et au sujet de contraintes FK en général).

1. Pourquoi faut-il utiliser ces procédures ?
2. Pourquoi les contraintes PK ne figurent pas dans sysconstraintes (dans quelle table sys sont-elles alors) ?
3. Pourquoi les contraintes FK sont bien recensées dans sysconstraintes sans que la procédure sp_foreignkey ne soit exécutée?

Un exemple de création de nos tables:

Code :

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

1
2
3
4
5
6
7
8
9
10
create table DR_xxx (
    DIR_xxx         date                   not null,
    DIR_yyy        date                   null,
    idDateIxxx     int                      not null,
    UTI_ccc        char(3)               not null,
    constraint PK_DR_DATE_ggg primary key nonclustered (idDateIxxx)
 
alter table DR_xxx
    add constraint FK_xxx__zzz foreign key (UTI_ccc)
    references UTI (UTI_ccc)

Merci
msomso

[Fabien Celaia]

syskeys est référencée à titre informatif afin que certains logiciels l'utilisant puissent le faire correctement. Par contre elle n'a que valeur informationnelle. Il en va tout autre de syscontraints

[mpeppler]

On pourra ajouter que sp_primarykey et consoeur dates de la version 4.0 (env 1989, peut-être même la 3.5?) de Sybase, alors que les contraintes référentielles déclaratives date de la version 10 (env 1995, si mes souvenirs sont bons)

Michael

[msomso]

Bonjour,

Compte tenu de vos remarques, voici mes dernières questions

1. En pratique, utilisez-vous uniquement les déclarations des contraintes via create/alter table ?
2. Dans quelle table système puis-je trouver la liste des PK ?
3. Avez-vous testé l'influence sur les performances de type de déclaration des FK (au niveau de colonne/table )?
   Nous générons nos scripts avec Power AMC ainsi toutes les FK sont au niveau de table (via cde "Alter table ... add FK).
   Pensez-vous que cela peut dégrader les performances ?

Merci
msomso