Discussion :

[Fritzoune]

Bonjour,
on me demande de loguer le résultat d'une requête, afin de savoir quels enregistrements posent problèmes, sachant que les requêtes vont insérer des tables entières ( et je suis sous sql 2005).

Basiquement ma requête était:

Code :

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

1
2
3
4
	INSERT afm.bl(bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon)
	SELECT bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon
	FROM afm.afm1_bl
	WHERE afm.afm1_bl.bl_id NOT IN (SELECT bl_id FROM afm.bl )

(J'insère dans la nouvelle table, tout ce qui n'existe pas déjà).
Ensuite on me demande de loguer les erreurs dans une autre table..
Et la j'ai l'impression que je suis tombé dans une usine et je sais pas si j'ai trouvé une bonne solution(même si ca semble bien marcher).
Pouvez-vous me conseiller ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
CREATE PROCEDURE afm.afm1_insert_all
AS
 
DECLARE
@myBLID varchar(50);
 
DECLARE myCursor CURSOR FOR
SELECT bl_id
			FROM afm.afm1_bl order by bl_id
			WHERE afm.afm1_bl.bl_id NOT IN (SELECT bl_id FROM afm.bl );
 
OPEN myCursor;
FETCH NEXT FROM myCursor
into @myBLID;
 
 
 
insert_block:
BEGIN TRY
	WHILE @@FETCH_STATUS= 0 
	BEGIN
		INSERT INTO afm.bl (bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon)
		SELECT bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon
		FROM afm.afm1_bl
		WHERE afm.afm1_bl.bl_id = @myBLID
 
		FETCH NEXT FROM myCursor
		into @myBLID;
	END
 
END TRY
BEGIN CATCH
	select        
		ERROR_NUMBER() AS ErrorNumber,
        ERROR_SEVERITY() AS ErrorSeverity,
        ERROR_STATE() AS ErrorState,
        ERROR_PROCEDURE() AS ErrorProcedure,
        ERROR_MESSAGE() AS ErrorMessage,
		@myBLID as bl_id;	
		FETCH NEXT FROM myCursor
		into @myBLID;
		GOTO insert_block	
END CATCH
 
CLOSE myCursor
DEALLOCATE  myCursor

J'ai pas encore fais le traitement dans le "catch" mais je vais insérer les infos que j'affiche là dans une autre table.


Donc une grosse procédure pour :
- voir l'enregistrement qui pose souci (la clé primaie = bl_id)
- une fois l'erreur levée, continuer le traîtement avec les autres enregistrements.

Estce que mon raisonnement est juste ?
Est-ce qu'on peut mieux faire et plus simplement ? J'ai pas mal de tables à faire selon ce principe, et ce n'est que les Inserts..

Au départ je voulais faire une procédure "insert" avec toutes mes requêtes d'insertions et avoir un TRY/Catch pour tout qui me remontrerai l'erreur, la table concernée et l'enregistrement (mais là je suis paumé).

[rudib]

Bonjour,

ton fonctionnement n'est pas idéal, les curseurs sont très contre-performants.

pourquoi ne pas identifier avant insertion les lignes qui vont provoquer des erreurs (par exemple, une clé étrangère qui n'a pas de référence dans une table-mère), et mettre ces lignes dans une table d'audit, en un seul INSERT, puis insérer les autres lignes, en une seule instruction, dans la bonne table ?

[Serguei_TARASSOV]

Bonjour,
on me demande de loguer le résultat d'une requête, afin de savoir quels enregistrements posent problèmes, sachant que les requêtes vont insérer des tables entières ( et je suis sous sql 2005).

Basiquement ma requête était:

Code :

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

1
2
3
4
	INSERT afm.bl(bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon)
	SELECT bl_id,name,site_id,cost_sqft,dwgname,ehandle,lat,lon
	FROM afm.afm1_bl
	WHERE afm.afm1_bl.bl_id NOT IN (SELECT bl_id FROM afm.bl )

(J'insère dans la nouvelle table, tout ce qui n'existe pas déjà).
Ensuite on me demande de loguer les erreurs dans une autre table..
Et la j'ai l'impression que je suis tombé dans une usine et je sais pas si j'ai trouvé une bonne solution(même si ca semble bien marcher).
Pouvez-vous me conseiller ?

Crée le trigger INSTEAD OF sur cette table qui fait le traitement en déplaçant les lignes incorrectes detectées dans une autre table.

[Fritzoune]

Ah ouais ca à l'air pas mal
Merci.
Je testerai ca sur le prochain projet
Les curseurs ont été acceptés et j'arrive a 15mn de traitements pour toute ma base, c'est pas trop dérangeant dans ce que j'ai du faire là.

[elsuket]

Bonjour,

Quelque soit l'utilisation que vous faites de votre base de données, surtout si elle est faible, 15 minutes est tout simplement inacceptable.

Avec une vraie requête SQL, le même traitement prendrait peut-être quelques secondes, comme je l'ai démontré ici .
A vous de voir si vous préférez faire dans la quantité de lignes de codes ou dans leur qualité ...

Ainsi votre INSERT peut directement s'écrire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
INSERT	INTO afm.bl
(
	bl_id
	, name
	, site_id
	, cost_sqft
	, dwgname
	, ehandle
	, lat
	, lon
)
SELECT		AFM1_B1.bl_id
		, AFM1_B1.name
		, AFM1_B1.site_id
		, AFM1_B1.cost_sqft
		, AFM1_B1.dwgname
		, AFM1_B1.ehandle
		, AFM1_B1.lat
		, AFM1_B1.lon
FROM		afm.afm1_bl AS AFM1_B1
LEFT JOIN	afm.bl AS B1 ON AFM1_B1.bl_id = B1.bl_id
WHERE		B1.bl_id IS NULL

Et la transaction sera totalement annulée si une seule erreur est rencontrée.
Il faut donc partir du libellé de l'erreur (que vous ne donnez pas) et rechercher ce qui en est la cause dans vos données.

@++

[Fritzoune]

Alors je suis entièrement d'accord avec vous,
sauf que:
je ne suis absolument pas un spécialiste SQL (et c'est pas faute de leur dire que c'est pas mon job..) et que les contraintes business l'emportent sur la qualité de ce script (vu que je ne maitrise pas vraiment le sujet, les heures passées à optimiser le script vont coûter bien plus cher que les 15mn (au lieu de 3) de traîtements à 2h du matin).
Et que ledit client est tout simplement insupportable, je souffre déjà assez comme ça

Ensuite votre requête ne permet pas de logguer l'enregistrement fautif.
Est-ce qu'avec le trigger instead of de Serguei; ca fonctionnerait ?

Le type d'erreur que je rencontre c'est soit des données trop grandes par rapport au champs d'arrivée, soit des contraintes d'intégrités ( clefs étrangères ) qui ne sont pas vérifées ou d'autres que je peux pas savoir avant de tenter de les importer.
Ou alors, avant de faire l'insert, il faudrait que je test chaque champ d'import s'il correspond à l'arrivée. Mais ca devient un travail de fourmi, qui n'était pas prévu dans le scope du projet à l'origine :S

Dur dur de devoir réaliser un projet quand la charte est pas bien définie par le commanditaire et que je suis pas spécialisé

[elsuket]

je ne suis absolument pas un spécialiste SQL (et c'est pas faute de leur dire que c'est pas mon job..) et que les contraintes business l'emportent sur la qualité de ce script (vu que je ne maitrise pas vraiment le sujet, les heures passées à optimiser le script vont coûter bien plus cher que les 15mn (au lieu de 3) de traîtements à 2h du matin).
Et que ledit client est tout simplement insupportable, je souffre déjà assez comme ça

Je peux le comprendre, j'ai été dans cette situation deux fois.
Donc j'ai démissionné deux fois, parce que je n'aime pas faire de la merde, et que souvent ne pas en faire, ce n'est pas aussi compliqué qu'on le croit.
Je ne vous blâme pas, je tire au boulet sur la vision à très court terme de la gestion du personnel et de sa formation par les entreprises IT de France.
C'est-à-dire que le coût de votre formation est bien moins cher que la source d'ennuis vers laquelle votre entreprise et ses clients se dirigent.

Ensuite votre requête ne permet pas de logguer l'enregistrement fautif.
Est-ce qu'avec le trigger instead of de Serguei; ca fonctionnerait ?

La solution de Serguei pourrait tout à fait fonctionner, mais elle ne vous exempt pas :

- d'utiliser mon exemple de code plutôt qu'un curseur,
- des erreurs à l'insertion

c'est soit des données trop grandes par rapport au champs d'arrivée, soit des contraintes d'intégrités ( clefs étrangères ) qui ne sont pas vérifées

C'est détectable en amont en deux requêtes

Ou alors, avant de faire l'insert, il faudrait que je test chaque champ d'import s'il correspond à l'arrivée. Mais ca devient un travail de fourmi, qui n'était pas prévu dans le scope du projet à l'origine :S

Je suis d'accord avec vous et ce sera très lent à faire en base de données.
Abandonnez tout simplement l'idée

Dur dur de devoir réaliser un projet quand la charte est pas bien définie par le commanditaire et que je suis pas spécialisé

Repensez à ce que j'ai écrit plus haut ... Je sais que le contexte actuel ne s'y prête pas.
Cela peut prendre du temps de changer d'entreprise, mais considérez aussi ce que cela peut apporter à votre carrière

@++