Microsoft 365 Mise à jour d'une Base ACCESS depuis Excel office365

[lericou]

Bonjour,

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

 

[Hasco]

Bonjour,

Essayer d'utiliser un curseur client (.CursorLocation= adUseClient).
N'ayant pas 365 ni abonnement sharepoint je ne peux pas tester.

Recordset, objet (ADO) - ActiveX Data Objects (ADO)

Recordset, objet (ADO)

learn.microsoft.com

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

En tous cas ne mélangez pas les deux méthodes.

 

[lericou]

Bonjour,

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

En tous cas ne mélangez pas les deux méthodes.

Merci beaucoup pour votre réponse
Je vais tester ce matin et je vous tiens au courant du résultat

 

[lericou]

Merci beaucoup pour votre réponse
Je vais tester ce matin et je vous tiens au courant du résultat

Merci beaucoup pour votre réponse
Je vais tester ce matin et je vous tiens au courant du résultat

Bonjour,

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

En tous cas ne mélangez pas les deux méthodes.

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

 

[Hasco]

Bonjour,

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.

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

Cordialement

 

[lericou]

Bonjour,

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

En tous cas ne mélangez pas les deux méthodes.

Bonjour,

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.

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

Cordialement

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!!!!

 

[Hasco]

Re,

En tous cas merci du retour, cela me servira, si un cas semblable se représente.

A bientôt