Ce problème peut se produire si votre ordinateur dispose d'au moins 1 Go de mémoire RAM.

Les problèmes de ce type sont résolus en appliquant le Office 97 Service Release 1. Ce service pack est disponible sur le site de Microsoft (voir lien ci-dessous).

Pour remédier à ce problème il faut respecter ces différentes étapes :

1. Installer le service pack 8 du moteur Jet (disponible sur le site Microsoft) ;
2. Puis dans la base de registre :
sous la clé : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines], créer ou modifier la valeur DWord nommée SandBoxMode avec la valeur 2,
sous la clé : [HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Access\Security], créer ou modifier la valeur DWord nommée Level avec la valeur 1.

Pour faire ceci automatiquement, vous pouvez créer le fichier .reg suivant qu'il vous suffira de lancer afin que lesdits changements s'appliquent.

Depuis le Bloc Note créez un fichier dans lequel vous mettrez le contenu suivant :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines]
"SandBoxMode"=dword:00000002

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Access\Security]
"Level"=dword:00000001

Enregistrez ce fichier avec l'extension .reg.

Raison probable : Par SQL, vous essayez de modifier quelque chose dans la même table (ou dans une des tables concernées) que celle affichée dans le formulaire actif.

Conclusion : si l'enregistrement que vous modifiez par SQL est contenu dans la même page (une page = le bloc d'enregistrements qu'Access bloque entièrement quand vous modifiez un seul enregistrement de la page) que l'enregistrement en cours dans le formulaire, il y a un conflit : deux utilisateurs à la fois (vous par formulaire + vous par SQL ou VBA...) essaient de modifier la même page en même temps. (Disons que ce message serait plus explicite que celui qu'Access affiche.)

La solution est délicate à mettre au point, mais en gros ça consiste à toujours enregistrer le formulaire avant de faire un quelconque accès aux données en écriture.
Quelque chose comme :

Private Sub Ouvré_AfterUpdate()
    If Me.Ouvré Then
        ' Enregistrer le formulaire, si besoin, avant une modif sur la base
        If Me.Dirty Then
            DoCmd.RunCommand accmdSaveRecord
        End If
        DoCmd.RunSQL "UPDATE T_JourOuvré " & _
                     "SET T_JourOuvré.ValeurPourCalculBrutVeille = 0 " & _
                     "WHERE (((T_JourOuvré.Date)=" & _
                     [Formulaires]![F_ValiderJourFériéMoisSuivant]![Date] & "));"
    End If
End Sub

"Pour arrêter l'affichage des avertissements liés aux macros, modifiez le niveau de sécurité sur la valeur Faible dans l'onglet Niveau de sécurité (dans le menu Outils, pointez sur Macro et cliquez sur Sécurité)."

Si vous n'avez pas l'option Sécurité dans le sous-menu Macro, vous pouvez l'y glisser-déposer en allant la chercher dans :
Menu Affichage -> Barres d'outils -> Personnaliser... -> Onglet Commandes -> Catégorie Outils -> Commande Sécurité...

On ne peut désactiver le contrôle qui est actif comme il est dit clairement dans le message.
Il vous suffit donc de donner le focus à un autre contrôle avant :

Private Sub MonBouton_Click()
Me.AutreBouton.SetFocus
Me.MonBouton.Enable = False
End Sub

Dans le cas où cette erreur arrive lors d'une requête SQL exécutée depuis VBA :
Vous essayez par exemple d'insérer une valeur dans un champ de type texte sans mettre d'apostrophe, exemple :

DoCmd.RunSQL "UPDATE MaTable SET nom=" & MaZonedeTexte & " WHERE id=" & ZonedeTexteID

Dans ce cas vous essayez de rentrer une valeur de dans le champ nom de type texte sans le mettre entre apostrophes.
Essayez plutôt :

DoCmd.RunSQL "UPDATE MaTable SET nom ='" & MaZonedeTexte & "' WHERE id=" & ZonedeTexteID

Ainsi cela fonctionnera. Pour mieux comprendre la différence entre les deux écritures, affichez les deux lignes grâce à des MsgBox, vous verrez rapidement la différence.
Je vous invite également à consulter le tutoriel de cafeine ci-dessous.

Cette erreur peut apparaître sur un poste alors que l'on n'a aucun problème sur un autre.
- Soit il y a une erreur de code (voir le détail chez Microsoft en suivant le lien plus bas).
- Soit la DLL DAO360.dll est absente (cas classique : il suffit de l'installer).
- Soit elle est présente mais mal enregistrée.

Microsoft conseille de désinstaller Office, puis de réinstaller.
Généralement, après ça marche.

Cas (très) particulier (et c'est la précision...) :
Si l'utilitaire de sauvegarde automatique d'Outlook est installé (backup des *.pst), on obtient l'erreur 429. Si on le désinstalle, ça marche. Il semble donc que les deux soient incompatibles.

L'erreur se déclenche uniquement si l'application "fille" (Word, Excel, Outlook...) est fermée. Si elle est ouverte, ça marche (CreateObject se comporte comme
GetObject).

Voilà, nous n'avons aucune explication technique à cela mais la désinstallation du backup d'Outlook a résolu notre problème.

Concernant cette erreur d'Access (97) voici une solution pour régler le problème.

1) Vérifiez dans le répertoire : C:\Program Files\Fichiers communs\Microsoft Shared\DAO\
que dao350.dll ainsi que dao360.dll sont bien présentes.
Si ce n'est pas le cas, une réinstallation s'impose...
2) Une fois cette vérification effectuée, ouvrez la base de registre (Démarrer, exécuter , taper : regedit).
3) Sauvegardez entièrement votre base de registre avant toutes modifications.
4) Une fois dans la base de registre, allez dans :
HKEY_CLASSES_ROOT\CLSID
5) Dans cette arborescence, vous devez trouver neuf clés se rapportant respectivement à dao350.dll et dao360.dll (respectez l'ordre).
Dans mon cas les neuf clés concernant la dll dao350 étaient manquantes même après réinstallation complète d'office 97 pro + patch SR2.
6) Une fois identifiées, il ne vous reste plus qu'à récupérer ces clés d'un autre poste (de version identique bien sûr) ou de les créer sur le modèle existant (exemple dao360).
Références des clés et sous-clés à créer :
{00000010-0000-0010-8000-00AA006D2EA4} à
InprocServer32
ProgID
{00000019-0000-0010-8000-00AA006D2EA4}

Dernière étape, il vous reste à rajouter dans l'arborescence HKEY_CLASSES_ROOT les clés :

DAO.DBEngine.35
DAO.Field.35
DAO.Group.35
DAO.Index.35
DAO.PrivateDBEngine.35
DAO.QueryDef.35
DAO.Relation.35
DAO.TableDef.35
DAO.User.35
HKEY_CLASSES_ROOT\Typelib
{00025E01-0000-0000-C000-000000000046}
4.0
5.0
{00025E04-0000-0000-C000-000000000046}

Faites une sauvegarde de la base.

Ensuite, dans Outils, option, Onglets Affichage, activez la case : Objets Systèmes.

Vous allez ainsi voir toutes les tables systèmes de la base. Essayez de supprimer les tables systèmes qui commencent par Temp. Normalement, après vous pourrez compacter.

Méthode douce, par Maxence Hubiche : dans la boîte à outils, cliquez sur le deuxième bouton (baguette magique) pour qu'il soit enfoncé.(Attention il s'agit de la baguette magique qu'il y a dans la BOITE À OUTILS pas dans la BARRE D'OUTILS.)

Méthode forte (si le problème n'a pas été résolu en douceur...), par dok flint : avant tout, assurez-vous que les assistants ont été sélectionnés dans les options d'installation d'Access. Si tel est le cas, alors le souci avec les assistants peut venir d'un problème au niveau d'Access. La solution est d'essayer de désinstaller Office puis de le réinstaller.
Si ça ne marche toujours pas, il faut employer les grands moyens, en réinstallant Windows.

Autre méthode : à l'aide de l'explorateur Windows, recherchez le fichier dao360.dll et notez son chemin.

Ensuite, allez dans le menu Démarrer\Exécuter et tapez :
regsvr32 "chemin_du_fichier/dao360.dll"
et cliquez sur OK.
Relancez Access.

Prenez votre fichier dll et déplacez-le vers WinSys32.
Ensuite cliquez deux fois dessus. Comme il risque de n'y avoir aucune association de fichier par rapport à l'extension DLL ce qui est normal, vous aurez la boite de dialogue permettant d'en sélectionner un qui va apparaître. De là, cliquez sur Parcourir...
Localisez regsvr32.exe dans le dossier WinSys32 et validez. Vous aurez un message indiquant qu'il est bien inscrit. Ensuite référencez-le proprement dans votre projet Access. Créez votre MDE après avoir compilé et vérifié votre code.
Il ne vous reste plus qu'à créer votre paquetage.

La réponse se trouve sur le site de Microsoft :

http://support.microsoft.com/default.aspx?scid=kb;fr;304548

Une solution possible est que ce soit un message d'empêchement de visualisation de projet lié à un problème de version. Par exemple, votre projet a été créé en Access 2000 et vous l'ouvrez avec Access XP ou 2003. Si c'est le cas, il faut d'abord le convertir au bon format avant de pouvoir accéder au code.

Il s'agit probablement d'une DLL manquante. Pour le savoir :
- aller dans un module (où il y a le code VBA) ;
- faire outils/référence.
La liste des dll s'affiche alors. À côté de l'une d'elles est sûrement écrit : "MANQUANTE" Il faut décocher cette référence et fermer le formulaire. Après, cela devrait fonctionner !

Pour corriger ce problème, allez dans le menu Outils - Options, cliquez sur l'onglet "Général" et pour l'option "Récupération d'erreur", sélectionnez la valeur "Arrêt sur les erreurs non gérées".

Pour éviter cette erreur, il faut définir le champ à trier et activer le tri.
L'ordre de tri se définit avec OrderBy et OrderByOn.

Placez le code dans Open_Report et mettez un On Error Resume Next au début.

On Error Resume Next
Me.OrderBy = "table.champ"
Me.OrderByOn = True

Suite à une migration de serveur, d'une version 97 d'Access sur un serveur Windows 2000 SP4
(Environnement CITRIX) à une version 2003 sur un serveur Windows 2003 Standard Edt SP1 (Environnement CITRIX PS4), une erreur "Argument Invalid" est levée.

Le problème vient de la version du fichier MSJET40.DLL.
Il faut qu'il soit en version 4.06 ou inférieure.
Or sous Windows 2003, la version est 4.09.
Il faut la remplacer en mode sans échec pour éviter la mise à jour du fichier en question par le système.

Lors de l'ouverture d'un état sans données un message d'erreur : "L'action Open Report a été annulée"
s'affiche, pour éviter cela il suffit d'intercepter l'erreur levée par Access (err 2501).
Le principe est de faire une gestion d'erreur.

Private Sub OpenReport()
On Error GoTo err_OpenReport

    DoCmd.OpenReport ("MonEtat")
    
    
err_OpenReport:
     Select Case err.Number
        Case 2501
            'rien à faire
        Case Else
            MsgBox err.Description
    End Select
End Sub

Dans une base Access gérant des images par lien lorsque l'on se déplace rapidement d'un enregistrement à l'autre au bout d'un moment il quitte purement et simplement sans message.

Apparemment c'est la boîte de dialogue de progression du filtre d'import qui n'apprécie pas la manipulation.
En empêchant cette boîte de progression d'apparaître, cela semble résoudre le problème.
Pour cela, il faut modifier la valeur de la clé de registre ShowProgressDialog.
Pour le filtre Jpeg par exemple :

HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Graphics filters\Export\Jpeg\Options\ShowProgressDialog = "No"

Lorsque vous sécurisez une base de données et que vous attribuez des droits à des groupes,
veuillez faire attention à ce que ces groupes doivent ou peuvent effectuer comme action dans l'application.
En effet, si des groupes doivent exécuter du code qui modifie une requête :
veillez à leur donner les droits en ce qui concerne la modification de la structure des requêtes, auquel cas cette erreur apparaîtra :

Erreur d'exécution 3033:
Vous n'avez pas l'autorisation requise pour utiliser l'objet MSysTables. Demandez l'autorisation requise à votre administrateur système ou la personne ayant conçu cet objet.

À noter : lorsque vous cocherez 'Modifier la structure' pour les requêtes, cette case sera systématiquement cochée pour les tables.

Fenêtre de base de données apparaît vide (version 2000 et 2002).
Avec des bases de données issues d'anciennes versions et qui n'ont pas été converties, la fenêtre de base de données peut s'afficher vide lorsque le mode d'affichage est en icône. Il suffit alors de changer de mode d'affichage (liste ou détails) pour faire apparaître les objets.
Une conversion et un compactage suffisent à régler ce problème.

Module inséré dans VBE n'apparaît pas dans la fenêtre base de données :
Il peut arriver suivant les versions d'Access qu'un module directement inséré à partir du VBE (clic droit dans l'explorateur de projet, Insérer un module)
n'apparaisse pas dans la fenêtre base de données.
Pourtant il y est et ses procédures et fonctions sont accessibles.
Il suffit de sauvegarder le nouveau module pour qu'il apparaisse dans la fenêtre de base de données.

Problème rapporté par isa911 :

Installation d'une base sur un nouveau poste, la touche shift est inactive sans l'avoir fait par code. Après analyse du problème le Runtime d'Access a été installé
avant Access. Dans le lien suivant vous trouverez la solution pour résoudre ce souci : Solution issue de MSDN (kb235280)

Il se peut lorsque vous intégrez des images avec l'extension jpg que vous rencontriez des soucis, Access vous signale que l'image n'est pas supportée,
pour cela vous pouvez télécharger sur le site de Microsoft une application corrigeant ce problème :

Office File Converter Pack