Discussion :

[Depite]

Bonjour,
Je travaille depuis quelques temps à la migration de la partie front-end réalisée sous forme d'un projet .ADP en base Access .ACCDB avec un Back-end SQL server 2008 R2 (l'objectif étant de pouvoir migrer cette partie vers la dernière version de SQL Server).

Je rencontre un problème que je ne parviens pas à comprendre:
Toute les tables sont attachées par une procédure unique qui définit la la chaine de connexion comme ceci:

Code :

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

ODBC;Description=MONPROJET DAO;DRIVER=SQL Server Native Client 11.0;SERVER=MONSERVEURSQL;Trusted_Connection=Yes;APP=TEST;DATABASE=MABASESQL;

Certaines tables attachées ne peuvent pas être mises à jour car au moment de l'enregistrement j'ai le message

Cet enregistrement a été modifié par un autre utilisateur depuis que vous avez commencé à le modifier...

Je précise que j'ai cette erreur en ouvrant directement la table dans Access en mode feuille de données et que ces tables disposent d'une clé primaire comme celles qui ne posent pas ce problème.
Si j'annule la mise à jour et que je la retente: idem
Bien sûr, si je reprends le projet .ADP je n'ai pas ce problème.

Est-ce que quelqu'un à une idée de l'origine du problème ?

Merci d'avoir pris le temps de lire ce message

[marot_r]

Bonjour.

Assure toi que la clef primaire fait bien partie des champs que tu récupères dans ton attachement.

Essaye de faire des modifications directement dans l'interface de visualisation de table pour t'assurer que cela ne vient pas de ton code.

Aussi vérifie que le mode de blocage des enregistrements est bien sur "Par enregistrement".
Note que ce terme est faux car Accces verrouille en réalité des bocs de 2 Ko de données donc si tu as des petits enregistrements il pourrait en bloquer plus de 1 à la fois.

A+

[Depite]

Merci d'avoir pris le temps de considérer mon problème Marot,

Les réponses à tes différentes suggestions figurent dans mon texte initial:
- Je fais les tests en ouvrant directement les tables
- Toutes les tables ont une clé primaire
- la clé primaire est inclue dans l'affichage (mode table)

Je ne passe par aucun formulaire ni aucun traitement, je pense que les tables qui posent ce problème (6 sur 83 dans cette base de données) doivent avoir un élément de configuration (contrainte, index?) qui provoque ce phénomène mais je ne parviens pas à l'identifier (
J'ai recréé une des tables sous un nouveau nom via un script de création généré à partir d'une des tables qui posent le problème en n'y ajoutant que la clé primaire (pas d'autre index ni aucune contrainte et pas de trigger bien sûr) je l'ai ensuite attachée dans un base MS Access 365 et il se passe la même chose

Une autre idée ?

Encore merci !

[tototiti2008]

Bonsoir,

une fois j'avais eu des soucis avec une table oracle attachée qui avait un champ date d'un type non supporté par Access et ça entrainait des problèmes, mais c'était plus violent que ce que tu décris
As-tu vérifié les types de données ?

Edit : je viens de vérifier, 255 objets liés (table attachée) max dans les versions avant 365, peut-être que la limite de 2010 était inférieure ?
Si tu enlèves une table attachée, peut-être relancer la base et voir si le nouveau lien fonctionne ?

[Depite]

Merci tototiti2008,

J'avais de toute façon envisagé cette possibilité et elle s'avère exacte et assez surprenante: c'est une colonne de type Int NULL qui provoque le problèmes - enfin pour l'instant car je n'ai eu le temps d'examiner une seule table (que j'ai dû découper en 10 pour localiser le défaut).
En modifiant la contrainte en NOT NULL après avoir forcé la valeur à zéro pour les lignes qui étaient nulles j'ai pu modifier les données de la table sans rencontrer de problème.

Je dois encore analyser les 7 autres tables qui présentent le souci pour déterminer s'il n'y a pas un autre type de colonne qui poserait ce problème.
Je donnerai le résultat et fermerai cette discussion lorsque j'aurai fini le tour.

Encore merci à tous.

[Depite]

Je reviens un peu tardivement sur ce sujet, excusez moï.

Après conversion complète de mon application il semble que seuls les colonnes de type bit permettant une valeur nulle soient génératrices du problème.

Pour l'instant j'ai converti toutes ces colonnes en type TinyInt autorisant les valeurs nulles (car la valeur nulle est significative pour la plupart d'entre elles) mais ça me pose un nouveau problème qui tient à la présentation de la valeur par un contrôle de type CheckBox car celui-ci ne gère pas correctement la conversion de sa valeur logique en entier (0,1,null).

J'envisage donc deux alternatives:

• Dissocier ces contrôles de la donnée source et affecter la valeur au moment du chargement des données en convertissant la valeur entière par l'équivalent logique puis procéder inversement lors du changement d'état

• Remplacer les cases à cocher par une liste déroulante proposant les trois valeurs en texte clair.

Est-ce que quelqu'un a un avis?

OFFICE 365
Par ailleurs est-ce que quelqu'un disposant d'Office 365 pourrait faire l'essai de cette configuration (table attachée avec une colonne de type Bit NULLABLE) source d'un formulaire dans lequel cette colonne est la source d'un contrôle de type CheckBox en vérifiant si les données peuvent être modifiées ?
Si c'est le cas j'envisagerai de passer sur cette version plus tôt que prévu!

Dans l'attente de votre aide que je sais toujours pertinente, bon codage

[Anton83]

Bonjour,

Je me permets de répondre, car j'ai eu un problème très similaire sur plusieurs applications Access 2024 en .accdb et .accde où sur certaines tables il était impossible de mettre à jour une quelconque donnée. Cela s'est produit quelques temps après avoir migré ces applications de Access 2003 vers Access 2024 et suite à l'utilisation du driver "ODBC Driver for SQL 17" idem avec le driver en version 18 !
Je me suis rendu compte que si j'utilisais l'ancien driver : "DRIVER=SQL Server" cela fonctionnait à nouveau.
Je viens tout juste de trouver la solution pour que ça fonctionne avec "ODBC Driver for SQL 17 ou 18".
Dans mon cas il s'agissait des champs DATETIME.
Mes tables liées proviennent d'un SQL SERVER (niveau de compatibilité = 130) et ces champs sont bien de type DATETIME et non DateTime2.
La solution se trouve dans les options d'Access, base de données active, Options de prise en charge du type de données, il faut cocher "Prise en charge du type de données Date Time Extended (DateTime2) pour les tables liées/importées ODBC" (par contre l'application ne pourra plus fonctionner en version 2003 !).
Je poste car, même si pour moi les champs Bit n'ont pas posé problème, j'ai bien galéré alors si ça peut servir à quelqu'un, c'est avec plaisir...

[User]

Merci pour le partage

[star]

Bonjour,
Le mieux serait de ne pas tenir compte des millisecondes dans la définition de la colonne Date de la table sousjacente
.