FileSystemWatcher sur ordinateur distant

Version imprimable

18/05/2012, 00h59
Jean-Marc68

FileSystemWatcher sur ordinateur distant

Salut à toutes et à tous,

Une application ouvre et effectue des modifications dans une base de données Access.
La base de données est sur un disque distant.
L'accès au disque distant est possible via les autorisations du user (nom de user et mot de passe) dans le domaine.
Jusqu'ici tout fonctionne bien. L'application ouvre et modifie la MDB.

Comme plusieurs utilisateurs peuvent accéder à la base de donnée. je dois recharger certaines tables.
En local (poste de développement), aucun problème. Tout fonctionne bien. Un fileSystemWatcher est déclenché et la mise à jour s'effectue.
Aussitôt que j'accède à la même base de donnée sur le disque distant, le FileSystemWatcher ne détecte plus rien (Par contre si l'utilisateur déclenche une mise à jour par le bouton, la mise à jour s'effectue. L'accès est donc correct).

Enfin, je précise que j'ai mis le InternalBufferSize à 65536 (64Ko, la limite pour les accès réseau d'après ce que j'ai lu sur msdn).

Quelqu'un aurait-il une idée, ou une autre méthode ?
Merci de vos z'avis z'avisés.
18/05/2012, 08h36
DonQuiche

Bonjour.

Là à froid je ne vois pas pourquoi, à part peut-être un mauvais chemin UNC (puisque c'est normalement la seule différence entre l'accès local et distant) ou un chemin long ou par volume ID (ce que dotnet ne supporte pas). J'essaierais également avec un buffer de 32k même si 65k est supposé être une valeur licite (effectivement la limite pour un accès distant).

Cela étant dit, il n'était pas possible d'utiliser SqlDependency plutôt ?
18/05/2012, 11h18
tomlev

Le fichier se trouve bien sur un serveur Windows, sur une partition NTFS ?
Si ce n'est pas le cas (par exemple fichier hébergé sur un partage Samba sous Linux), la notification ne fonctionnera pas...

Citation:

Envoyé par DonQuiche

Cela étant dit, il n'était pas possible d'utiliser SqlDependency plutôt ?

C'est seulement pour les bases SQL Server, pas pour Access

Salut et merci de vos réponses et de votre aide.

Le serveur est bien sur un serveur Windows avec partition NTFS, par contre je pense que le problème vient du Volume ID, comme dis DonQuiche.

Mais dans ce cas, comment dois-je faire pour que le fileSystemWarcher soit fonctionnel ?
Comment convertir le VolumeID en UNC utilisable par le FileSystemWatcher ?

Voici mon code actuel :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
            OpenFileDialog openFile = new OpenFileDialog();
            openFile.CheckFileExists = true;
            openFile.CheckPathExists = true;
            openFile.Multiselect = false;
            openFile.Title = "Sélection Base de donnée parcelles";
            openFile.DefaultExt = "MDB";
            openFile.Filter = "Base de donnée dessin (*.MDB)|*.MDB|Tous les fichiers (*.*)|*.*";
            DialogResult result = openFile.ShowDialog();
            if (result == DialogResult.OK)
            {
                DefaultDBInfos.DefaultDB_FileInfo = new FileInfo(openFile.FileName);
                this.Text = DefaultDBInfos.DefaultDB_FileInfo.Name;
                Parcelles parcellesForm = new Parcelles(this);
                parcellesForm.MdiParent = this;
                parcellesForm.Show();
                MDBFileSystemWatcher.Path = DefaultDBInfos.DefaultDB_FileInfo.DirectoryName;
                MDBFileSystemWatcher.Filter = DefaultDBInfos.DefaultDB_FileInfo.Name;
                MDBFileSystemWatcher.InternalBufferSize = 65536;
                MDBFileSystemWatcher.EnableRaisingEvents = true;
            }

J'ai trouvé le code suivant pour retourner l'UNC d'un chemin.
Je pense toutefois que je vais devoir me fabriquer un FileSystemWatcher parce qu'il ne me retourne rien sur la modification de base de données sur un disque distant, or j'alimente bien le FileSystemWatcher par un chemin UNC, maintenant.

Merci quand-même de vos avis et de vos conseils.

Code:

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
 
        [DllImport("mpr.dll", CharSet = CharSet.Unicode, SetLastError = true)]
        public static extern int WNetGetConnection(
            [MarshalAs(UnmanagedType.LPTStr)] string localName,
            [MarshalAs(UnmanagedType.LPTStr)] StringBuilder remoteName,
            ref int length);
        /// <summary>
        /// Given a path, returns the UNC path or the original. (No exceptions
        /// are raised by this function directly). For example, "P:\2008-02-29"
        /// might return: "\\networkserver\Shares\Photos\2008-02-09"
        /// </summary>
        /// <param name="originalPath">The path to convert to a UNC Path</param>
        /// <returns>A UNC path. If a network drive letter is specified, the
        /// drive letter is converted to a UNC or network path. If the
        /// originalPath cannot be converted, it is returned unchanged.</returns>
        public static string GetUNCPath(string originalPath)
        {
            StringBuilder sb = new StringBuilder(512);
            int size = sb.Capacity;
 
            // look for the {LETTER}: combination ...
            if (originalPath.Length > 2 && originalPath[1] == ':')
            {
                // don't use char.IsLetter here - as that can be misleading
                // the only valid drive letters are a-z && A-Z.
                char c = originalPath[0];
                if ((c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z'))
                {
                    int error = WNetGetConnection(originalPath.Substring(0, 2),
                        sb, ref size);
                    if (error == 0)
                    {
                        DirectoryInfo dir = new DirectoryInfo(originalPath);
 
                        string path = Path.GetFullPath(originalPath)
                            .Substring(Path.GetPathRoot(originalPath).Length);
                        return Path.Combine(sb.ToString().TrimEnd(), path);
                    }
                }
            }
 
            return originalPath;
        }