Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème DTS / Insertion dans une table

10 réponses
Avatar
David G.
Bonjour,

Sous Sql Server 2000 (MSDE SP4), lors de l'insertion dans une table, j'ai le
message suivant :

[Microsoft][ODBC SQL Server Driver][SQL Server]Impossible d'allouer de
l'espace pour l'objet 'Appels' dans la base de données 'Base' parce que le
groupe de fichiers 'PRIMARY' est plein.

Le problème c'est que j'ai 23Go de libre sur le disque où se trouve la base,
12Go sur mon autre disque et ma base est configurée en Automatic growth,
sans limite de taille pour le fichier de données et le fichier journal. Je
ne comprends donc pas pourquoi je ne peux pas insérer mes données dans ma
table.

Déjà pendant le DTS la table Appels avait posé problème. J'ai du effectuer 2
passes (DTS avec requête pour diminuer les enregistrements concernés à
chaque passe) et stocker les données dans la table Résultats créée par
défaut lors de l'utilisation de requête sur le DTS, car en passant
directement par la table Appels, en 2 passes ca ne suffisait pas.

Je ne comprends vraiment pas ce qui pose problème. Je vais réessayer le DTS
encore une fois, en attendant que quelqu'un puisse m'aider ^^

10 réponses

Avatar
Bouarroudj Mohamed
Exécute dbo.sp_helpfile pour voir les drivers qui "hostent" votre BD, puis
dbo.xp_fixeddrives pour voir l'espace disponible.

Si vous avez beaucoup de donnés à transférer il est préférable de les
transférer par batch afin de ne pas créer des grandes transactions qui vont
exploser votre journal des transactions.




"David G." wrote in message
news:e2sm$
Bonjour,

Sous Sql Server 2000 (MSDE SP4), lors de l'insertion dans une table, j'ai
le message suivant :

[Microsoft][ODBC SQL Server Driver][SQL Server]Impossible d'allouer de
l'espace pour l'objet 'Appels' dans la base de données 'Base' parce que le
groupe de fichiers 'PRIMARY' est plein.

Le problème c'est que j'ai 23Go de libre sur le disque où se trouve la
base, 12Go sur mon autre disque et ma base est configurée en Automatic
growth, sans limite de taille pour le fichier de données et le fichier
journal. Je ne comprends donc pas pourquoi je ne peux pas insérer mes
données dans ma table.

Déjà pendant le DTS la table Appels avait posé problème. J'ai du effectuer
2 passes (DTS avec requête pour diminuer les enregistrements concernés à
chaque passe) et stocker les données dans la table Résultats créée par
défaut lors de l'utilisation de requête sur le DTS, car en passant
directement par la table Appels, en 2 passes ca ne suffisait pas.

Je ne comprends vraiment pas ce qui pose problème. Je vais réessayer le
DTS encore une fois, en attendant que quelqu'un puisse m'aider ^^



Avatar
Med Bouchenafa
Peux-etre que tu arrives à la limite des 2Go de MSDE

--
Bien cordialement
Med Bouchenafa
"David G." a écrit dans le message de news:
e2sm$
Bonjour,

Sous Sql Server 2000 (MSDE SP4), lors de l'insertion dans une table, j'ai
le message suivant :

[Microsoft][ODBC SQL Server Driver][SQL Server]Impossible d'allouer de
l'espace pour l'objet 'Appels' dans la base de données 'Base' parce que le
groupe de fichiers 'PRIMARY' est plein.

Le problème c'est que j'ai 23Go de libre sur le disque où se trouve la
base, 12Go sur mon autre disque et ma base est configurée en Automatic
growth, sans limite de taille pour le fichier de données et le fichier
journal. Je ne comprends donc pas pourquoi je ne peux pas insérer mes
données dans ma table.

Déjà pendant le DTS la table Appels avait posé problème. J'ai du effectuer
2 passes (DTS avec requête pour diminuer les enregistrements concernés à
chaque passe) et stocker les données dans la table Résultats créée par
défaut lors de l'utilisation de requête sur le DTS, car en passant
directement par la table Appels, en 2 passes ca ne suffisait pas.

Je ne comprends vraiment pas ce qui pose problème. Je vais réessayer le
DTS encore une fois, en attendant que quelqu'un puisse m'aider ^^



Avatar
David G.
"Med Bouchenafa" a écrit dans le message de news:

Peux-etre que tu arrives à la limite des 2Go de MSDE

--
Bien cordialement
Med Bouchenafa



Effectivement il semble que cela soit la raison du problème, je ne savais
pas que l'on était limité à 2Go sous MSDE. Je vais réessayer sur un Sql
Server 2000 normal et le problème devrait ainsi être réglé.

Je vais profiter de ce sujet, pour aborder une autre question si vous le
voulez bien. Je dois m'occuper d'une migration d'une base de données, de
Sybase vers Sql Server 2000. Quelqu'un avant moi avait déjà regardé le sujet
et établi une manière de procéder. En gros, on extrait la structure sous
forme de script afin de recréer le squelette de la base sous Sql Server
2000, par DTS on réintègre les données et ensuite par un script on
réapplique les clés et index. C'est cette dernière étape qui pose problème.
Pour une raison que j'ignore, j'ai, pour certaines contraintes, le message
suivant :

L'introduction d'une contrainte de clé étrangère 'MaContrainte' dans la
table 'MaTable' peut provoquer des cycles ou des accès en cascade multiples.
Spécifiez ON DELETE NO ACTION ou ON UPDATE NO ACTION ou modifiez les autres
contraintes de clés étrangères.

Sur les contraintes qui bloquent, j'ai soit ON DELETE CASCADE soit ON UPDATE
CASCADE ON DELETE CASCADE (pour l'update c'est discutable car on ne va pas
modifier l'identifiant normallement, mais c'est pour rester fidèle à la base
originale). Mais d'autres contraintes possédant ces mêmes propriétés ne
posent pas de soucis.

Si vous pouviez éclairer ma lanterne concernant ce problème, son contexte
(pourquoi certaines contraintes seulement ? que peuvent elles avoir de
particulier ? car je ne vois rien de spécial), ... je vous en serais
reconnaissant ^^

Merci encore :-)
Avatar
Med Bouchenafa
C'est une limite de SQL Server qui n'a malheureusement pas été levée dans
2005

Soit une table des employes contenant :
l'identifiant de l'employé
l'identifiant de son chef qui est aussi un employé
L'identifiant du departement de rattachement. L'information est dans
tblDepartment
Mais un employé peut travailler pour plusieurs département.
L'information est stockée dans la table tblDepEmp
L'identifiant de la fonction de cet employée. L'information est dans
tblFunction
L'identifiant de sa fonction ultérieure. L'information est dans
tblFunction

Cela donne quelque chose qui ressemble à ceci
use tempdb
go
CREATE TABLE tblDepartment
(
DepartmentID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
DepartmentName VARCHAR(64)
)
CREATE TABLE tblEmployee
(
EmployeeID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
DepartmentID INT NOT NULl REFERENCES tblDepartment(DepartmentID) ON
DELETE CASCADE,
ManagerID INT NULL,
FunctionID1 INT NULL,
FunctionID2 INT NULL,
)
CREATE TABLE tblFunction
(
FunctionID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
FunctionName VARCHAR(64)
)
CREATE TABLE tblDepEmp
(
DepartmentID INT NOT NULL,
EmployeeID INT NOT NULL
)

Dans l'absolu, on peut modéliser autrement mais ce modèle est assez logique
et simple. Il est même parfaitement normalisé.
Et pourtant la pose des contraintes suivantes ne passe pas

1) Un chef doit forcement être un employé. Cela ne passe pas
ALTER TABLE tblEmployee ADD CONSTRAINT FK FOREIGN KEY (ManagerID) REFERENCES
tblEmployee(EmployeeID) ON DELETE CASCADE

2) La première fonction passe mais pas la seconde
ALTER TABLE tblEmployee ADD CONSTRAINT FK1 FOREIGN KEY (FunctionID1)
REFERENCES tblFunction(FunctionID) ON DELETE CASCADE
ALTER TABLE tblEmployee ADD CONSTRAINT FK2 FOREIGN KEY (FunctionID2)
REFERENCES tblFunction(FunctionID) ON DELETE CASCADE


3) Aucune des deux contraintes ne passent !!!
ALTER TABLE tblDepEmp ADD CONSTRAINT FK3 FOREIGN KEY (DepartmentID)
REFERENCES tblDepartment(DepartmentID) ON DELETE CASCADE
ALTER TABLE tblDepEmp ADD CONSTRAINT FK4 FOREIGN KEY (EmployeeID) REFERENCES
tblEmployee(EmployeeID) ON DELETE CASCADE


Il y a peut-être d'autres cas
La solution serait d'utiliser des triggers
Je serais cependant curieux de savoir comment réagissent les autres SGBDR,
notamment SYBASE dans le cas présent


Bien cordialement
Med Bouchenafa

"David G." a écrit dans le message de news:
%
"Med Bouchenafa" a écrit dans le message de news:

Peux-etre que tu arrives à la limite des 2Go de MSDE

--
Bien cordialement
Med Bouchenafa



Effectivement il semble que cela soit la raison du problème, je ne savais
pas que l'on était limité à 2Go sous MSDE. Je vais réessayer sur un Sql
Server 2000 normal et le problème devrait ainsi être réglé.

Je vais profiter de ce sujet, pour aborder une autre question si vous le
voulez bien. Je dois m'occuper d'une migration d'une base de données, de
Sybase vers Sql Server 2000. Quelqu'un avant moi avait déjà regardé le
sujet et établi une manière de procéder. En gros, on extrait la structure
sous forme de script afin de recréer le squelette de la base sous Sql
Server 2000, par DTS on réintègre les données et ensuite par un script on
réapplique les clés et index. C'est cette dernière étape qui pose
problème. Pour une raison que j'ignore, j'ai, pour certaines contraintes,
le message suivant :

L'introduction d'une contrainte de clé étrangère 'MaContrainte' dans la
table 'MaTable' peut provoquer des cycles ou des accès en cascade
multiples. Spécifiez ON DELETE NO ACTION ou ON UPDATE NO ACTION ou
modifiez les autres contraintes de clés étrangères.

Sur les contraintes qui bloquent, j'ai soit ON DELETE CASCADE soit ON
UPDATE CASCADE ON DELETE CASCADE (pour l'update c'est discutable car on ne
va pas modifier l'identifiant normallement, mais c'est pour rester fidèle
à la base originale). Mais d'autres contraintes possédant ces mêmes
propriétés ne posent pas de soucis.

Si vous pouviez éclairer ma lanterne concernant ce problème, son contexte
(pourquoi certaines contraintes seulement ? que peuvent elles avoir de
particulier ? car je ne vois rien de spécial), ... je vous en serais
reconnaissant ^^

Merci encore :-)



Avatar
David G.
Merci pour l'information :-)

Dans Sybase, cela ne pose absolument aucun problème. La base actuelle que
j'essaye de migrer, pour des fins de tests uniquement pour le moment,
possède plusieurs contraintes (60 en tout d'après les erreurs après passage
en Sql Server) qui rentrent dans ce cadre.

Le comportement, pour la version de Sybase que j'utilise en tout cas, est
vraiment différent, même pour des index déclaré comme unique par exemple. Si
on déclare un index unique sur 4 champs d'une table. Si l'un d'eux est à
NULL, la contrainte d'index unique ne sera pas prise en compte pour cet
enregistrement, ce qui fait que l'on peut avoir plusieurs lignes pour un
index marqué comme unique sous Sybase et cela pose évidemment problème
lorsque l'on passe sous Sql Server ^^

Bref les clés étrangères "récursives" sont impossibles, ainsi que d'avoir 2
clés étrangères dans une table qui pointent sur une même table. Il
semblerait donc qu'une table ne puisse être présente au plus qu'une fois
dans les appels en cascade. C'est dommage parce que cela oblige à recourir à
des "lourdeurs" pour palier ce manque : les triggers ou revoir
l'architecture de la base.

Je vais me pencher sur la chose donc. Merci encore.

"Med Bouchenafa" a écrit dans le message de news:
%
C'est une limite de SQL Server qui n'a malheureusement pas été levée dans
2005



Avatar
Med Bouchenafa
Tu as joué le script du précedent message et c'est passé sans problème sur
SYBASE
Interessant!!
Si ça peut te rassurer, j'ai pu créer sans aucun problème toutes les
contraintes du précédent message sur...ACCESS.
A aucun moyen, je n'ai eu le moindre message d'erreur.
Il est vrai qu'ACCESS a géré les contraintes en cascade bien bien avant SQL
Server.

Idéalement, il faudrait que je pousse mes tests jusqu'a remplir la table
Employés avec des données et faire une suppression d'un employé qui aurait
un chef, lui-même ayant un chef
J'ai mis nos amis d'access dans la boucle, ils pourraient peut-être nous en
dire plus

Pour ta migration, jette un coup d'oeil à ces ressources
http://www.microsoft.com/sql/prodinfo/compare/sybase.mspx


Bien cordialement
Med Bouchenafa

"David G." a écrit dans le message de news:

Merci pour l'information :-)

Dans Sybase, cela ne pose absolument aucun problème. La base actuelle que
j'essaye de migrer, pour des fins de tests uniquement pour le moment,
possède plusieurs contraintes (60 en tout d'après les erreurs après
passage
en Sql Server) qui rentrent dans ce cadre.

Le comportement, pour la version de Sybase que j'utilise en tout cas, est
vraiment différent, même pour des index déclaré comme unique par exemple.
Si
on déclare un index unique sur 4 champs d'une table. Si l'un d'eux est à
NULL, la contrainte d'index unique ne sera pas prise en compte pour cet
enregistrement, ce qui fait que l'on peut avoir plusieurs lignes pour un
index marqué comme unique sous Sybase et cela pose évidemment problème
lorsque l'on passe sous Sql Server ^^

Bref les clés étrangères "récursives" sont impossibles, ainsi que d'avoir
2
clés étrangères dans une table qui pointent sur une même table. Il
semblerait donc qu'une table ne puisse être présente au plus qu'une fois
dans les appels en cascade. C'est dommage parce que cela oblige à recourir
à
des "lourdeurs" pour palier ce manque : les triggers ou revoir
l'architecture de la base.

Je vais me pencher sur la chose donc. Merci encore.

"Med Bouchenafa" a écrit dans le message de news:
%
C'est une limite de SQL Server qui n'a malheureusement pas été levée dans
2005






Soit une table des employes contenant :
l'identifiant de l'employé
l'identifiant de son chef qui est aussi un employé
L'identifiant du departement de rattachement. L'information est dans
tblDepartment
Mais un employé peut travailler pour plusieurs département.
L'information est stockée dans la table tblDepEmp
L'identifiant de la fonction de cet employée. L'information est dans
tblFunction
L'identifiant de sa fonction ultérieure. L'information est dans
tblFunction

Cela donne quelque chose qui ressemble à ceci
use tempdb
go
CREATE TABLE tblDepartment
(
DepartmentID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
DepartmentName VARCHAR(64)
)
CREATE TABLE tblEmployee
(
EmployeeID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
DepartmentID INT NOT NULl REFERENCES tblDepartment(DepartmentID) ON
DELETE CASCADE,
ManagerID INT NULL,
FunctionID1 INT NULL,
FunctionID2 INT NULL,
)
CREATE TABLE tblFunction
(
FunctionID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
FunctionName VARCHAR(64)
)
CREATE TABLE tblDepEmp
(
DepartmentID INT NOT NULL,
EmployeeID INT NOT NULL
)

Dans l'absolu, on peut modéliser autrement mais ce modèle est assez logique
et simple. Il est même parfaitement normalisé.
Et pourtant la pose des contraintes suivantes ne passe pas

1) Un chef doit forcement être un employé. Cela ne passe pas
ALTER TABLE tblEmployee ADD CONSTRAINT FK FOREIGN KEY (ManagerID) REFERENCES
tblEmployee(EmployeeID) ON DELETE CASCADE

2) La première fonction passe mais pas la seconde
ALTER TABLE tblEmployee ADD CONSTRAINT FK1 FOREIGN KEY (FunctionID1)
REFERENCES tblFunction(FunctionID) ON DELETE CASCADE
ALTER TABLE tblEmployee ADD CONSTRAINT FK2 FOREIGN KEY (FunctionID2)
REFERENCES tblFunction(FunctionID) ON DELETE CASCADE


3) Aucune des deux contraintes ne passent !!!
ALTER TABLE tblDepEmp ADD CONSTRAINT FK3 FOREIGN KEY (DepartmentID)
REFERENCES tblDepartment(DepartmentID) ON DELETE CASCADE
ALTER TABLE tblDepEmp ADD CONSTRAINT FK4 FOREIGN KEY (EmployeeID) REFERENCES
tblEmployee(EmployeeID) ON DELETE CASCADE


Il y a peut-être d'autres cas
La solution serait d'utiliser des triggers
Je serais cependant curieux de savoir comment réagissent les autres SGBDR,
notamment SYBASE dans le cas présent


Bien cordialement
Med Bouchenafa











Avatar
David G.
"Med Bouchenafa" a écrit dans le message de news:

Tu as joué le script du précedent message et c'est passé sans problème sur
SYBASE
Interessant!!



C'est passé comme une lettre à la poste. Je vais voir le lien que tu as
posté concernant la migration Sybase vers Sql Server 2000, peut être
j'aurais de nouvelles pistes à explorer :-)
Avatar
David G.
J'ai bien compris le problème en ce qui concerne les DELETE. Par contre pour
ce qui est des UPDATE, je ne vois pas où est le cycle, à part le cas évident
des clés étrangères récursives ou bien des clés étrangères multiples (N clés
dans une table qui poitent sur la même table parent).

Dans l'exemple suivant, je ne vois vraiment pas ce qui bloque. La dernière
contrainte ne peut être mise en place, mais je ne sais pas pourquoi, je ne
vois vraiment pas où je crée un "cycle" (désolé pour les noms, je ne suis
pas très imaginatif :-P).

CREATE TABLE Table1
(
Table1ID INT NOT NULL IDENTITY PRIMARY KEY
)

CREATE TABLE Table2
(
Table2ID INT NOT NULL IDENTITY PRIMARY KEY,
Table1FK INT
)

CREATE TABLE Table3
(
Table3ID INT NOT NULL IDENTITY PRIMARY KEY,
Table1FK INT,
Table2FK INT
)

ALTER TABLE Table2
ADD CONSTRAINT FK1 FOREIGN KEY (Table1FK) REFERENCES
Table1(Table1ID) ON UPDATE CASCADE

ALTER TABLE Table3
ADD CONSTRAINT FK2 FOREIGN KEY (Table1FK) REFERENCES
Table1(Table1ID) ON UPDATE CASCADE

ALTER TABLE Table3
ADD CONSTRAINT FK3 FOREIGN KEY (Table2FK) REFERENCES
Table2(Table2ID) ON UPDATE CASCADE

Si vous pouviez m'éclairer encore un peu là dessus :-)
Avatar
Med Bouchenafa
En fait, je suppose table3 reférence table2 qui elle même référence table1
Si tu modifies table1, tu demandes à SQL Server de répercuter le changement
dans table2.
Ce changement de table2 doit aussi se répecurter dans table3
Il sait apparemment pas faire...ou n'accepte pas de prendre le risque de
faire

--
Bien cordialement
Med Bouchenafa

"David G." a écrit dans le message de news:
%23I$
J'ai bien compris le problème en ce qui concerne les DELETE. Par contre
pour ce qui est des UPDATE, je ne vois pas où est le cycle, à part le cas
évident des clés étrangères récursives ou bien des clés étrangères
multiples (N clés dans une table qui poitent sur la même table parent).

Dans l'exemple suivant, je ne vois vraiment pas ce qui bloque. La dernière
contrainte ne peut être mise en place, mais je ne sais pas pourquoi, je ne
vois vraiment pas où je crée un "cycle" (désolé pour les noms, je ne suis
pas très imaginatif :-P).

CREATE TABLE Table1
(
Table1ID INT NOT NULL IDENTITY PRIMARY KEY
)

CREATE TABLE Table2
(
Table2ID INT NOT NULL IDENTITY PRIMARY KEY,
Table1FK INT
)

CREATE TABLE Table3
(
Table3ID INT NOT NULL IDENTITY PRIMARY KEY,
Table1FK INT,
Table2FK INT
)

ALTER TABLE Table2
ADD CONSTRAINT FK1 FOREIGN KEY (Table1FK) REFERENCES
Table1(Table1ID) ON UPDATE CASCADE

ALTER TABLE Table3
ADD CONSTRAINT FK2 FOREIGN KEY (Table1FK) REFERENCES
Table1(Table1ID) ON UPDATE CASCADE

ALTER TABLE Table3
ADD CONSTRAINT FK3 FOREIGN KEY (Table2FK) REFERENCES
Table2(Table2ID) ON UPDATE CASCADE

Si vous pouviez m'éclairer encore un peu là dessus :-)



Avatar
David G.
Si je modifie l'identifiant dans Table1, la modification sera répercutée sur
Table2 et Table3 (champs Table1FK), mais Table2 ne répercutera pas la
modification vers Table3 puisqu'il n'y a aucun lien sur le champ Table1FK
entre Table2 et Table3 et c'est bien pour ca que je ne comprends pas le
problème du cascade et des cyles dans ce cas.
En suppression, le cycle aurait été évident, mais pas sur une mise à jour.
Ou alors Sql Server prend le cas le plus "large", à savoir la suppression,
pour tester les cycles même dans le cas où il n'y a qu'une mise à jour.

Je n'ai trouvé aucune documentation précise sur ce problème et c'est bien
malheureux.

"Med Bouchenafa" a écrit dans le message de news:
eDz%
En fait, je suppose table3 reférence table2 qui elle même référence table1
Si tu modifies table1, tu demandes à SQL Server de répercuter le
changement dans table2.
Ce changement de table2 doit aussi se répecurter dans table3
Il sait apparemment pas faire...ou n'accepte pas de prendre le risque de
faire

--
Bien cordialement
Med Bouchenafa