Reprise du message précédent :
J'ai pris le projet en cours de route aussi, j'ai rien pu dire sur la BD
Sinon ya pas une idée pour faire avec une requête récursive ???

va falloir m'expliquer le concept  

En + c'est fun si il commence avoir un truc cyclique, histoire de bien tuer la DB avec une requete qui fini jamais
(apparemment vaut mieux s'enliser dans le truc que prendre 10 minutes pour corriger le design)

J'ai jamais dis ca, j'ai dis que ca m'interessait de savoir comment ca marchait une requete récursive, parce que je connaissais pas du tout. Crois moi si je pouvais modifier la BD, je le ferai, mais bon... j'ai pas le droit

Dans ces cas-là, tu démontre au client que modifier la DB serait beaucoup plus logique, efficace, lui rapporterait des millions, etc...  et il te donnera l'accord pour faire les modifs    

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

j'ai toujours pas compris comment une requête pouvait s'appeler elle-même  

Ben moi non plus je comprends pas mais je sais que ca existe

 
une stored procedure peut s'appeler elle même, non ?

oui un SP ou une fonction OK, mais une bête requête, je vois pas  

http://msdn2.microsoft.com/fr-fr/library/ms186243.aspx
Je suis en train de regarder comment ca marche...

spa vraiment une requête ça  

sais pas, ils appellent ca requete récursive...

Question alakon : y'a pas moyen de faire un delete ou un truncate sans que SQL Server ne fasse exploser le log ?
Parce que bon ... ca me saoule d'avoir mon HD qui me dit "low disk space" à tout bout de champ chaque fois que je fais une manip sur cette p* de database.

Bah un TRUNCATE ca doit faire quasiment rien niveau log
Ou tu parles du log pour le rollback?

wep le truncate fait quasi rien effectivement. (comme un con j'avais lancé un delete sur 24 mio de records, vraiment pas le truc à faire)

loser  

EDIT: le mieux qd tu ne veux pas faire de truncate et que tu dois supprimer plus de 10% de la table, est de créer une table temporaire avec un create table as select des rows que tu veux garder, faire un truncate de la table originale, remettre les données gardées ds la bonne table et supprimer la table temporaire

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(ca foutra juste le bordel avec tous les triggers et autres que tu risques d'avoir a chaque insert et compagnie, sans parler des ON DELETE sur les foreign keys pendant le delete mais c'est pas graf)
Sinon suffit d'faire une boucle avec plusieurs DELETE sur une plus petite range

Faut voir la table mais c'est le plus performant logiquement  

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(seulement avec une logique de consultant qui a fait 1 semaine de formation acceleree Oracle)

Spour ça que ça avait été conseillé chez Belgacom pour des tables avec des centaines de millions de records  

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(forcement, une boite de consultants c'est rempli de consultants)
(edit: mais content de savoir qu'y a pas de cles etrangeres dans vos DBs, ca doit etre super consistent )

C'est pas ma DB, c'est la DB de chez Belgacom... Je ne travaille pas là-bas moi  
EDIT: et c'est pas un type de chez nous qui avait fait ça

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(c'etait probablement un consultant d'ailleurs)

En fait je suppose que cette méthode est plus particulièrement adaptée aux DWH plutôt qu'aux bases de données opérationelles. Car là, désactiver les contraintes et les triggers hors période de chargement ne pose pas vraiment de problèmes.

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

Une contrainte c'est pas fait pour etre desactive

A priori, dans ce cas-ci, tu ne changes pas de données donc désactiver la contrainte ne pose pas de problèmes car tu es sur que les données qui restent seront tjrs valides

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(c'est sur, ton ON DELETE CASCADE il ferait des tas d'autres DELETEs mais ca change rien)

C'est ce que je disais tout-à-l'heure, tout dépend sur quelle table c'est fait . Et puis, normalement, qd tu supprimes un grand nombre de données, ce n'est pas des tables parents

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

Hm je vois que tu as une grande experience des DBs
Edit: allez, pour te faire plaisir: eventuellement dans 5% des cas ta methode est pas trop foireuse

 
C'est bon t'as gagné, t'es le meilleur, le plus beau, etc...  

---------------
Belge et fier de l'être - Smileys
Membre du Club des Fanatiques d'ubuntu

(je sais)

Anyway ici le but c'est de vider TOUTE la table donc le truncate cay parfait (d'hab on fait pire, on droppe et on recrée la table vierge paske bon ossafou c'est des db de dev de merde)

Le bon vieux install.sql qui commence par un DROP DATABASE

ouep en gros c'est ca sauf qu'ici pour une fois je devais conserver 4 des 10 tables (des petites tables annexes qui ont pas changé)

Bon, j'aimerai savoir si c'est possible de verifier l'existance d'un fichier en T-SQL.
En gros je dois faire une procédure stockée qui fait une sauvegarde d'une base et que si le fichier de sauvegarde existe, on fait rien, sinon on sauvegarde.
Et sinon, est ce que c'est possible, toujours en T-SQL de supprimer un fichier ?

xp_delete_file ou un truc du genre
edit: ou xp_cmdshell
edit2: ou FSO (probablement le + flexible)
edit3: ou du .NET directement

 
+1 : Scripting.FileSystemObject
 
EDIT: exemple

Merci Vais regarder ca.