Discussion :

[kargozegon]

Bonjour à tous,
Je ne suis pas développeur et en désespoir de cause je viens exposer mon problème sur ce forum afin de parvenir à mettre un poste de saisie de données en prod. Le problème étant d'ordre professionnel, il me faut trouver une solution malgré mon incompétence en la matière.

Le problème recouvre 2 aspects touchant l'un à Access, l'autre à SQL. Je ne suis pas l'auteur du masque de saisie Access ni de la base de données et aucun de mes prestataires informatiques n'a su me donner de piste pour me sortir de l'impasse. J'ajouterai tous les éléments que vous jugerez pertinent à cette description.

Environnement:
Le poste client tourne sous windows XP 2002 SP2
il utilise Access 2002.
Le serveur tourne sous Windows server 2003 R2
La base sous SQL 2005

Le hardware est Anglais et les softs français.

1er Problème:
Sur un plateau de saisie, j'ai 8 postes avec configs identiques. Tous utilisent une application access identique (ce sont toutes les copies de la même application) pour se connecter sur la base SQL. Les 7 premiers se connectent, le 8e, le plus récemment arrivé n'a jamais voulu se connecter.

Lorsque je lance l'application depuis ce poste, je n'obtiens même pas le formulaire de login. un message d'erreur s'affiche avec comme titre:

L'action a échoué

Nom de la macro:
AutoExec

Condition:
Vrai

Nom de l'action:
ExécuterCode

Arguments:
demarrage()

La seule option que j'ai à ce niveau, c'est de cliquer sur le bouton 'arrêter'. 'Pas à pas' et 'continuer' sont grisés.

2e problème:
Du coup, j'ouvre mon application et affiche les éléments qui la composent. Je double clic sur le formulaire de login que devrait afficher l'appli lors de son lancement. Il s'affiche, je tape mon identifiant et mon mot de passe et là, 2 cas de figure:

1er cas j'obtiens ce message d'erreur:

Echec lors de la connexion
Etat SQL: 'S1000'
Erreur SQL server: 0
[Microsoft][ODBC SQL server driver]Impossible de générer le contexte SSPI

2e cas de figure:
le client se connecte et j'accède à mes enregistrements saisis, mais l'affichage de mes données n'est pas conforme à ce qu'il devrait être.

Normalement, certains enregistrements qui ne doivent plus être modifiés comporte un champ 'valide' qui lorsqu'il vaut 1, grise l'enregistrement et empêche toute modification.
Ceux qui ne sont pas validés (valide=0) peuvent être modifiés et tous les champs sont disponibles.

Pourtant, dans ce cas de figure où je parviens, aléatoirement me semble t-il, à accéder à mes enregistrements, la totalité des enregistrements auxquels j'accède par mon formulaires de saisies proposent 50% de champs accessibles et l'autre moitié grisée et immodifiable.

Le 1er problème provient manifestement d'Access. Je ne parviens pas à exécuter la macro autoexéc et je ne sais pas réaliser d'exécution pas à pas ni vérifier les valeurs que renvoie chaque ligne de code, donc au final, je n'ai pas identifié le point de la macro qui empêche son exécution.

Lorsque je me mets dans la fonction 'Demarrage' qui sert d'argument à cette macro et que j'appuie sur Exécution, il ne se passe rien. Le module dans lequel se trouve la fonction 'demarrage' s'appelle 'main', donc pas de conflit lié à une redondance due au nom me semble t-il.

Pour le 2e problème, je ne suis sûr de rien. J'ai navigué dans la Base de connaissance Microsoft mais les éléments à vérifier sont nombreux et souvent hors de mon champ de compréhension (Les forêts sous active directory et l'authentification Kerberos me sont très peu familières, je ne suis que simple utilisateur et n'ai aucune notion de programmation, d'admin réseau ou d'admin SGBD).

Quelques précisions supplémentaires à toutes fins utiles:

• L'authentification utilisée dans les sources de données système ODBC est celle de Windows NT.
• Les drivers SQL sont identiques sur les 8 postes (strictement la même version)
• J'ai contrôlé les autorisations liées à l'utilisateur sur mon domaine et il fonctionne sur les 7 autres postes. Cet utilisateur est valide et fonctionnel.

J'ai les codes admin du réseau d'entreprise et puis rechercher les éléments pertinents si on me dit où chercher.

Merci d'avance pour la coopération des membres de ce forum que je visite de plus en plus pour essayer de comprendre l'outil que j'utilise (et qui n'a pas été bien développé au départ, j'en ai peur).

En espérant que ces éléments sont exploitables dans la compréhension de mon problème qui immobilise totalement un poste de saisie tout neuf que je n'ai pu mettre en production depuis 1 mois maintenant.

[Heureux-oli]

Première chose, tu n'est pas développeur, c'est pas grave moi non plus, au moins nous sommes deux !

Seconde chose, bienvenue sur les Forums Office de DVP.

Tu as très bien expliqué ton problème, et c'est peu courant.

Ne cherche pas au niveau de la forêt et AD, ce n'est pas la source de ton problème. AD ne sert que pour la structure de ton réseau et les droits liés au machines et utilisateurs.

Par contre, je pencherai pour un problème de ODBC, pourrais-tu tester la connection ODBC au départ de la machine vers la base SQL, il est possible que certains paramètres ne soient pas bon.

Vérifie également la version de ton pilote ODBC, ce n'est peut-être pas la bonne version.

Pour l'exécution de la macro, c'est plus complexe, on ne peut savoir ce qu'elle contient.

Essaie lors du démarrage d'Access de maintenir la touche Maj ou Shift enfoncée pour inhiber ou tenter d'inhiber certains processus, et essaie ensuite de naviguer dans l'application.

[kargozegon]

Merci de ce sympathique accueil.

Le test de sources de données ODBC système et utilisateur renvoient toujours un succès.

Les drivers SQL sont identiques sur les 8 postes (strictement la même version)

Comme précisé dans le premier post de présentation, j'ai vérifié les pilotes.

Sur tous les postes, j'ai 2 types de pilotes ODBC pour SQL:
SQL Native client 2005.90.1399.00
SQL server 2000.85.1117.00

A priori, je n'utilise que le second.

Ces pilotes ont tous été installés à partir des mêmes CD sur tous les postes de saisie et ils permettent une connexion normale sur les 7 premiers postes.

Maintenant que j'ai testé cela, je m'aperçois que j'ai omis une bizarrerie de taille dans mon descriptif. Lorsque je définis une nouvelle sources de données ODBC, je dois lui affecter un serveur source. Je donne en premier lieu le nom de la base, un descriptif, puis je choisis quel serveur abrite la source de données. Il se trouve que le serveur que je souhaite contacter apparait en triple dans la liste déroulante de ce champ.
Cela me semblait anodin au départ puisque d'autres postes posaient le même problème apparent et aucun n'avait présenté de problème de connexion.

Ce peut-il que ce poste en particulier ait du mal à résoudre l'adresse de ce serveur uniquement et que cela le perturbe?

En ce qui concerne l'application, je peux regarder dedans mais je ne sais pas quoi chercher.

Voici une copie du code de la fonction intitulée 'demarrage' qui se trouve elle même dans un module nommé 'Main'. Cette fonction 'demarrage' sert d'argument à une action exécutercode qui compose la macro Autoexéc:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Option Compare Database
Option Explicit
 
Global Operateur As String
Global NivAuth As Integer
Global nomuser As Variant
Global prenomuser As Variant
Global NumMedia As Variant
Global datediffus As Variant
Global repencours As Variant
 
Global Const SW_SHOWNORMAL = 1
Const CST_ERREUR_PROP_NON_TROUVEE = 3270
 
Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
 
Public Function demarrage() As Boolean
 
    Dim args As String
    args = Command
    Select Case args
        Case "prod"
            'TODO : mettre les option pour le prochain demarrage.
            Call setDatabaseProperties("AllowBypassKey", dbBoolean, False)
            Call setDatabaseProperties("AllowSpecialKeys", dbBoolean, False)
            MsgBox "Base de donnée configurer pour la production !"
            Application.Quit acQuitSaveAll
        Case "dev"
            Call setDatabaseProperties("AllowBypassKey", dbBoolean, True)
            Call setDatabaseProperties("AllowSpecialKeys", dbBoolean, True)
            MsgBox "Base de donnée configurer pour le developpement !"
            Application.Quit acQuitSaveAll
        Case Else
            DoCmd.OpenForm ("fLogin")
    End Select
 
    demarrage = True
 
End Function
 
Public Sub setDatabaseProperties(propertiesName As String, dataType As DataTypeEnum, value As Variant)
    On Error Resume Next
    Dim prp As Variant
 
    CurrentDb.Properties(propertiesName) = value
 
'   Si il y a une erreur alors il faut crée la propriete
    If Err.Number = CST_ERREUR_PROP_NON_TROUVEE Then
        Set prp = CurrentDb.CreateProperty(propertiesName, dataType, value)
        CurrentDb.Properties.Append prp
    ElseIf Err.Number <> 0 Then
        MsgBox Err.Description
    End If
 
    On Error GoTo 0
End Sub

J'ajoute Ici une image écran de la macro.

Merci de ton aide.

[Domi2]

Bonjour,

Ce serait très étonnant, mais ce serait trop bête de chercher plus loin si c'est le cas !

N'aurais-tu pas une référence marquée manquante (depuis un module, Menu Outils ==> Références). si une référence est marquée manquante, tu la décoches.

Domi2

[kargozegon]

Merci Domi2, ça règle une partie de la question. Le problème 1 disparait.

Maintenant lorsque j'active mon application, le formulaire de login s'ouvre comme il le devrait. Reste le problème 2. Une fois mon mdp rentré, j'écope de ce message

Echec lors de la connexion
Etat SQL: 'S1000'
Erreur SQL server: 0
[Microsoft][ODBC SQL server driver]Impossible de générer le contexte SSPI

Il me demande ensuite d'utiliser la connexion approuvée qui échoue avec le même message.

[Domi2]

Re,

Là...

Pour prodéder par élimination, encore vérifier les références.

Sur un poste valide, regarde quelles sont les références cochées, et les fichiers utilisés. Puis, regarder dans le système les dates et versions.

Et faire la comparaison sur le PC où tu as le problème.

J'ai pas mieux...

Domi2