Les rapports de sauvegarde SMO ne peuvent pas ouvrir le périphérique de sauvegarde (qui est un file), Message 3201

Ce code fonctionne correctement sur une instance SQL Server Express locale:

Dim thisSMOBackup As New Backup() With thisSMOBackup .Database = singleDatabase.Name 'This contains the database name .Action = BackupActionType.Database .Devices.AddDevice(DatabaseFileName, DeviceType.File) .Incremental = False .LogTruncation = BackupTruncateLogType.Truncate End With Try thisSMOBackup.SqlBackup(thisServer) 'thisServer is setup w/ valid connection ssortingng and reads back data OK from the SQL server System.IO.File.AppendAllText(logfileName, singleDatabase.Name & " - backed up") Catch ex As Exception System.IO.File.AppendAllText(logfileName, singleDatabase.Name & " - " & ex.InnerException.Message & vbCrLf) End Try 

Lorsque j'applique le même code à un server SQL Server partagé, il génère le message d'erreur d'exception interne suivant:

Impossible d'ouvrir le périphérique de sauvegarde 'D: \ aFolderName \ aBackupName \ theDatabaseName.bak'. Erreur du operating system 3 (Le système ne trouve pas le path spécifié.). BACKUP DATABASE se termine anormalement.
Message #: 3201

Il semble y avoir différentes façons de se connecter aux servers. Pour l'instance SQL Server Express, j'utilise la propriété .ServerInstance , pour le server hébergé, j'utilise la propriété .ConnectionSsortingng . Cela a-t-il quelque chose à voir avec le fonctionnement du code SMO?

J'ai lu que les servers d'hébergement partagés SQL peuvent avoir des ressortingctions qui sont difficiles à surmonter, mais avant que j'abandonne, je voulais requestr des commentaires.

L'erreur elle-même suggère SMO ne peut pas find l'location pour écrire le file, mais il est là, et j'ai mis la security pour le dossier "Tout le monde" avec "Contrôle total". Mais alors les erreurs ne semblent pas toujours signifier exactement ce qu'elles disent. Je me demandais s'il y avait d'autres parameters que je devais configurer pour que cette opération réussisse, ou d'autres endroits à regarder.

Lorsque vous essayez de créer une sauvegarde dans votre environnement d'hébergement partagé, le file de sauvegarde est en cours d'écriture sur le système de files de ce server distant ( PAS le vôtre, lecteur D: local!) Où votre SQL Server est en cours d'exécution.

Très probablement, le count d'user qui exécute SQL Server à distance n'a tout simplement pas l'autorisation d'écrire dans ce directory.

Aussi: c'est une bonne chose ! Après tout, vous ne voudriez pas d'un server distant que vous ne connaissez pas et que vous ne contrôlez pas pour avoir un access direct en écriture à votre propre machine locale – et maintenant?

Ce que vous pouvez faire (particulièrement dans un environnement d'entreprise) consiste à écrire des sauvegardes dans un path UNC ( \\server\share\path ) auquel l' \\server\share\path SQL Server distant a access en écriture et auquel vous avez au less un access en lecture. , afin que vous puissiez y aller et copyr les files .bak sur votre machine locale au besoin. Avec une société d'hébergement commercial, cette option existe très rarement, cependant ….