Discussion :

[joomy78]

Bonjour à tous,
est-il possible de lire et stocker la date de modification d'un fichier, dont le chemin est stocké dans un champ?

je pensais que ce serait facile, mais il semble que ce ne soit plus possible depuis SQL server 2008

merci

[tatayo]

Bonjour,
Qu'est-ce que tu entends par "fichier" et "champs" ?

Tatayo.

[joomy78]

Bonjour,
Le fichier est stocké sur un serveur de fichier.
et pour le champ, c'est le lien vers ce fichier, qui est dans une case d'une table sql
ex: \\serveur\emplacement\monfichier.jpg

j'espère être un peu + clair

[SQLpro]

Utilisez vous FILESTREAM ?

A +

[joomy78]

Bonjour,
je ne connaissais pas FILESTREAM, mais d'après ce que je vois, il s'agit d'une façon de stocker dans une table des données de type image ou document?
Si c'est le cas, ça ne correspond pas car je ne maîtrise pas le lieu de stockage, je n'ai qu'un "lien" vers le fichier stocké sur un serveur de fichiers.

[SQLpro]

Non, c'est plus sophistiqué que cela ....

Le FILESTREAM correspond à ce que la norme SQL apelle le DATALINK. C'est en fait un pointeur interne, dans une colonne de table, pointant vers un fichier externe dont le lieu de stockage est bien un répertoire du disque. Mais c'est SQL Server qui gère le fichier et non plus directement l'OS (les fichiers sont sous le contrôle du SGBDR).
Avantages :
cela fait partie de la transaction (en cas de rollback, le fichier n'est pas déposé ou supprimé)
en cas de sauvegarde de la base, les fichiers sont concernés comme s'ils étaient dans la base
le SGBDR maintient l'intégrité des données y compris pour les fichiers. Par exemple s'il y a dépendance (FOREIGN KEY) en cas de suppression de la table maître, les lignes filles peuvent être supprimées dans la foulé (ON DELETE CASCADE) et les fichiers disparaissent.

En fait en externalisant les fichiers comme tu l'as fait, il n'y a aucun moyen de garantir l'intégrité. Peu à peu tu te retrouve avec des fichiers en trop ou en moins et en cas de restauration, c'est le merde.

Il y a enfin un dernier moyen c'est la FileTable qui est un dérivé du FILESTREAM et qui consiste à créer une table "système" pointant vers un répertoire de ton système de fichier pour les manipuler en SQL comme par le système de fichier. Dans ce cas, dans la "filetable" tu verras le nombre d'octets de tes fichiers.

A lire sur le sujet :
https://docs.microsoft.com/fr-fr/sql...l-server-ver15

Tu peut bien entendu "greffer" une filetable sur le répertoire de ton choix...

A +

[aieeeuuuuu]

bonjour,

Ce n'est pas trop le rôle d'un SGBDR que d'aller récupérer ce type d'informations. Pourquoi ne pas passer par un programme externe qui récupère la date du fichier et mets à jour la base de données, ou éventuellement une fonction SQL CLR ?

Pouvez vous en dire plus sur le contexte ?

[joomy78]

Bonsoir,
merci pour l'info du filetable: je vais l'étudier pour voir l'intérêt et voir également le filestream.
en fait, dans mon projet, il y a énormément de médias qui sont dans beaucoup de dossiers différents.
Ces fichiers sont créés par des personnes différentes.
Effectivement, si le fichier est supprimé, le lien ne doit plus exister, et c'est bien le cas, une routine à base de xp_filexist s'occupe d'éliminer les "liens cassés".

C'est vrai que ce n'est pas trop le rôle du SGBDR de récupérer ces dates, en tous cas c'est ce que microsoft nous a fait comprendre en supprimant cette fonctionnalité
je pense donc que ce sera un programme VBnet qui maintiendra cette donnée.

[Boubou2020]

une chose proche de ce ci

Code :

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

1
2
3
4
5
6
7
8
9
10
 
$fileList = Get-ChildItem -Path $SourceDir -Filter *.xlsx -File |  ForEach-Object -Process {$_.LastWriteTime}
#Write-SQL table
$DestServer = 'servername'
$DestDB = 'dbname'
$Schema = 'sch'
$DestTbl = 'tblname'
foreach ($file in $fileList){
(import-excel -path $file ‑NoHeader -erroraction stop ) |
write-sqltabledata -servername $DestServer -databasename $DestDB -schemaname $Schema -tablename $DestTbl -force -erroraction stop}

[SQLpro]

Bonsoir,
merci pour l'info du filetable: je vais l'étudier pour voir l'intérêt et voir également le filestream.
en fait, dans mon projet, il y a énormément de médias qui sont dans beaucoup de dossiers différents.
Ces fichiers sont créés par des personnes différentes.
Effectivement, si le fichier est supprimé, le lien ne doit plus exister, et c'est bien le cas, une routine à base de xp_filexist s'occupe d'éliminer les "liens cassés".
[/CODE]Extrémement dangereux, car votre utilisateur doit avec le contrôle total du serveur pour ce faire.... Il pourra par exemple détruire toutes vos bases par injection de SQL ![CODE]
C'est vrai que ce n'est pas trop le rôle du SGBDR de récupérer ces dates, en tous cas c'est ce que microsoft nous a fait comprendre en supprimant cette fonctionnalité
je pense donc que ce sera un programme VBnet qui maintiendra cette donnée.

Bof, bof !

A +