J'ai créé un fichier Excel avec des macro Vba qui permet de se connecter à une base Access située sur un SharePoint.
Chaque utilisateur dispose du même fichier Excel sur le bureau de son PC.
Tous les utilisateurs ont accès en lecture et écriture sur la base distante.
Tous les utilisateurs qui procèdent Excel (2010, 2012, 2016, 2019) peuvent écrire et lire dans la base Access.
Par contre les utilisateurs d'Excel 365 n'arrivent pas à écrire dans cette base, POURQUOI ???
Il semblerait qu'office 365 créé une copie de la base distante en local. (De ce fait la base dans laquelle je veux écrire n'est pas mise à jour), POURQUOI ???
Si quelqu'un peux me trouver une solution qui me permette d'écrire dans ma base distante avec Excel 365, je l'en remercie d'avance.
Pour Info voici mon code de connexion à ma base ACCESS
Global Gdb As ADODB.Connection
Global DirPathBase As String
Global WarPswd As String
Public Sub ConnectMdb()
WarPswd = "Toto"
DirPathBase = "\\share.xxx.fr@SSL\DavWWWRoot\sites\0412\MaBase.accdb"
Set Gdb = CreateObject("ADODB.Connection")
With Gdb
.Provider = "Microsoft.ACE.OLEDB.12.0"
.ConnectionTimeout = 30
.IsolationLevel = adXactIsolated
.CursorLocation = adUseServer
.Mode = adModeReadWrite
.Open "Data Source=" & DirPathBase & "; User Id=Admin; MS Access; pwd=" & WarPswd
End With
While (Gdb.State = adStateConnecting)
DoEvents
Wend
End Sub
Par contre je vois que vous utilisez la liaison tardive, et la liaison direct en même temps, ce qui n'est jamais recommandé pour une bonne gestion de la mémoire.
Soit vous référencez une bibliothèque Adodb (en priant pour que ce soit la même sur tous les postes)
vous créer vos objets avec le mot clef NEW : Set Gdb = NEW Adodb.Connection
Avec cette méthode vous avez accès aux constantes Adodb et facilités de saisie de code
Soit vous ne référencez aucune bibliothèque et vous créez vos objets avec CreateObject, laissant le système s'arranger avec les versions.
Dans ce dernier cas, déclarez GDB AS Object
Avec cette méthode vous devez employez les valeurs des constantes : 2 pour AdUseServer et 3 pour AdUseClient
Essayer d'utiliser un curseur client (.CursorLocation= adUseClient).
N'ayant pas 365 ni abonnement sharepoint je ne peux pas tester.
Par contre je vois que vous utilisez la liaison tardive, et la liaison direct en même temps, ce qui n'est jamais recommandé pour une bonne gestion de la mémoire.
Soit vous référencez une bibliothèque Adodb (en priant pour que ce soit la même sur tous les postes)
vous créer vos objets avec le mot clef NEW : Set Gdb = NEW Adodb.Connection
Avec cette méthode vous avez accès aux constantes Adodb et facilités de saisie de code
Soit vous ne référencez aucune bibliothèque et vous créez vos objets avec CreateObject, laissant le système s'arranger avec les versions.
Dans ce dernier cas, déclarez GDB AS Object
Avec cette méthode vous devez employez les valeurs des constantes : 2 pour AdUseServer et 3 pour AdUseClient
Essayer d'utiliser un curseur client (.CursorLocation= adUseClient).
N'ayant pas 365 ni abonnement sharepoint je ne peux pas tester.
Par contre je vois que vous utilisez la liaison tardive, et la liaison direct en même temps, ce qui n'est jamais recommandé pour une bonne gestion de la mémoire.
Soit vous référencez une bibliothèque Adodb (en priant pour que ce soit la même sur tous les postes)
vous créer vos objets avec le mot clef NEW : Set Gdb = NEW Adodb.Connection
Avec cette méthode vous avez accès aux constantes Adodb et facilités de saisie de code
Soit vous ne référencez aucune bibliothèque et vous créez vos objets avec CreateObject, laissant le système s'arranger avec les versions.
Dans ce dernier cas, déclarez GDB AS Object
Avec cette méthode vous devez employez les valeurs des constantes : 2 pour AdUseServer et 3 pour AdUseClient
Merci beaucoup pour votre réponse
Je viens de tester, mais c'est toujours pareil (Excel 365 écrit dans une Mdb tampon qui est je ne sais où et non dans la bonne Mdb).
Voici les modifications apportées à mon code
Global Gdb As Object
Global DirPathBase As String
Global WarPswd As String
Public Sub ConnectMdb()
WarPswd = "Toto"
DirPathBase = "\\share.xxx.fr@SSL\DavWWWRoot\sites\0412\MaBase.accdb"
Set Gdb = CreateObject("ADODB.Connection")
Set Gdb = New ADODB.Connection
With Gdb
.Provider = "Microsoft.ACE.OLEDB.12.0"
.ConnectionTimeout = 30
.IsolationLevel = adXactIsolated
.CursorLocation = adUseClient
.Mode = adModeReadWrite
.Open "Data Source=" & DirPathBase & "; User Id=Admin; MS Access;pwd=" & WarPswd
End With
While (Gdb.State = adStateConnecting)
DoEvents
Wend
End Sub
Vous pouvez inspecter dans la fenêtre variable locales les propriétés de votre connexion.
Voyez s'il y a un conflit en la propriété nommée "Data Source" et celle nommée "Data Source Name"
Le modèle suivant vous permet d'afficher dans la fenêtre exécution tous les noms des propriétés de la connexion.
Remplacer les "-------" par le chemin vers votre base de données.
Si vous placez un point d'arrêt sur la ligne "With .Properties" et ouvrez la fenêtre des variables locales vous pourrez examiner le contenu de la collection.
VB:
Const DATASOURCE As String = "---------\ASampleDatabase.accdb"
Sub TestConnection()
Dim oCnx As Object
Dim i As Integer
Set oCnx = CreateObject("adodb.connection")
With oCnx
.connectionstring = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & DATASOURCE & ";Persist Security Info=False;"
.Open
With .Properties
For i = 1 To .Count
Debug.Print .Item(i - 1).Name
Next
End With
.Close
End With
Set oCnx = nothing
End Sub
Essayer d'utiliser un curseur client (.CursorLocation= adUseClient).
N'ayant pas 365 ni abonnement sharepoint je ne peux pas tester.
Par contre je vois que vous utilisez la liaison tardive, et la liaison direct en même temps, ce qui n'est jamais recommandé pour une bonne gestion de la mémoire.
Soit vous référencez une bibliothèque Adodb (en priant pour que ce soit la même sur tous les postes)
vous créer vos objets avec le mot clef NEW : Set Gdb = NEW Adodb.Connection
Avec cette méthode vous avez accès aux constantes Adodb et facilités de saisie de code
Soit vous ne référencez aucune bibliothèque et vous créez vos objets avec CreateObject, laissant le système s'arranger avec les versions.
Dans ce dernier cas, déclarez GDB AS Object
Avec cette méthode vous devez employez les valeurs des constantes : 2 pour AdUseServer et 3 pour AdUseClient
Vous pouvez inspecter dans la fenêtre variable locales les propriétés de votre connexion.
Voyez s'il y a un conflit en la propriété nommée "Data Source" et celle nommée "Data Source Name"
Le modèle suivant vous permet d'afficher dans la fenêtre exécution tous les noms des propriétés de la connexion.
Remplacer les "-------" par le chemin vers votre base de données.
Si vous placez un point d'arrêt sur la ligne "With .Properties" et ouvrez la fenêtre des variables locales vous pourrez examiner le contenu de la collection.
VB:
Const DATASOURCE As String = "---------\ASampleDatabase.accdb"
Sub TestConnection()
Dim oCnx As Object
Dim i As Integer
Set oCnx = CreateObject("adodb.connection")
With oCnx
.connectionstring = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & DATASOURCE & ";Persist Security Info=False;"
.Open
With .Properties
For i = 1 To .Count
Debug.Print .Item(i - 1).Name
Next
End With
.Close
End With
Set oCnx = nothing
End Sub
Merci pour votre réponse,
Mais après multi tests aujourd'hui avec les IT de ma société,
Il s'est avéré que le SharePoint de ma société est au format office 2019.
A savoir qu'un SharePoint fonctionne un peu comme un fichier Excel en mode partagé.
c'est à dire comme un ticket tournant qui met à jour les entrées au fur et à mesure des modifications.
En conclusion, j'ai déplacé ma base Access sur un serveur dédié, et là Ho miracle, que la base soit attaquée par un Excel 201X ou 365, les MàJ sont instantanées.
En gros, éviter de mettre un mdb sur un SharePoint!!!!