none
Runtime access 2007 v2 + windows 7=> Erreurs RRS feed

  • Question

  • Bonjour,

    j'ai répertorié une série de bugs reproductibles se produisant uniquement sous win 7 et access runtime 2007.
    Certains sont très ennuyeux, car je n'ai pas de solution simple, et laisser les clients sous win xp n'est pas une solution.
    Le plus ennuyeux (mais ce n'est pas le seul) concerne des formulaires continus et une zone "expression" (pas basée sur un champs exclusivement). Il faut forcer l'update de l'écran par un 'f9' (et ca ne résoud pas tout). Un exemple "reproductible" peut être téléchargé ici: http://www.kineuro.com/accessBugs/runtime

    Je pensais que le souci était lié au dcount/dlookup, mais j'ai le souci sans même utiliser ces fonctions.

    En 2010 ca marche mieux mais j'ai d'autres soucis avec les footers (problème 2 de la même page).

    Je me demande, après avoir passé quelques heures sur le net, s'il y a une solution "connue" ou si je suis le seul à faire des applications access utilisant des formulaires continus?

    Toute réponse/aide est la bienvenue, je serais bien étonné d'être le seul dans le cas.

    Alain


    Alain Bourgeois
    dimanche 20 mars 2011 23:51

Réponses

Toutes les réponses

  • Bonjour,

    "Il faut forcer l'update de l'écran par un 'f9' (et ca ne résoud pas tout)."

    Est-ce à dire que vos zones de texte munis d'expression restent vides ?

    Quelles sont ces expressions ?

    Que donne ce comportement avec votre BDD source sur votre poste renommée en ACCDR ?


    Argy
    jeudi 24 mars 2011 13:27
    Modérateur
  • 1. Est-ce à dire que vos zones de texte munis d'expression restent vides ?
    Ca veut dire que les textes remplis d'expression se calculent en général correctement, mais que moins d'une minute après, sans que rien ne soit demandé à access, le runtime fait un refresh et relance le calcul, les zones redeviennent blanches en attente du résultat du calcul. Donc il faudrait relancer des F9 toutes les x secondes, en espérant que le client ne soit pas en train de taper.

    2. Quelles sont ces expressions ?
    Des DLookup, des DCount, et des appels de fonction vba. En fait toutes les expressions lisant des enregistrements plantent. J'ai remplacé les dlookup et dcount par des fonctions vba utilisant des recordset, ca ne résoud rien du tout. Dans le cas d'un formulaire continu, on passe à ces fonctions des paramètres relatifs au record concerné (ID ou autre), et cela semble lui poser problème.
    Ce qui semble avoir une influence, c'est que les paramètres de la fonction soient des zones sur un formulaire (même venant d'un autre formulaire), ou que les fonctions référencent des zones de formulaire, ou que les fonctions appellent des requètes faisant des filtres sur des zones d'un formulaire.
    J'ai même une table avec une zone [ID Traitement] spéficiée dans un paramètre de l'appel de fonction. Le fait de renommer dans le formulaire la zone en [IDTraitement] (sans espace, en gardant le nom avec espace dans le controlsource) change déjà le comportement du bidule (sous runtime et win 7 - pour rappel, tous ces cas et exemples fonctionnent très bien avec le même run-time 2007 et les autres windows vista / xp).
    Vous pouvez télécharger le cas avec espace http://www.kineuro.com/accessBugs/runtime/kineuro_Test.mdb et sans espace http://www.kineuro.com/accessBugs/runtime/kineuro_Test2.mdb
    Le problème est facile à reproduire: créer une base avec deux tables, un formulaire continu, et mettre une zone dans le détail avec comme controlsource un dlookup.
    Autre exemple sans dlookup/dcount: http://www.kineuro.com/accessBugs/runtime/attest.mdb.

    3. Je n'ai pas testé, il faut dire que cette solution ne m'intéresse pas pour les raisons suivantes:
    * J'ai converti le .mdb en .accdb sous access 2007 et testé ce .accdb sous runtime: aucun changement, ca plante tout autant,
    * Je distribue des mdb, format access 2000,
    * mes clients téléchargent des mises à jour (des .mdb) qui insèrent/remplacent des objets (rapports, requètes, formulaires, modules, macros) dans le programme.mdb du client (ce qui n'est pas possible avec un .mde ou un .accdr à ma connaissance),
    * La plupart de mes clients sont sous access 2000 à 2003 ou sous des windows antérieurs (et heureusement, car avec les bugs du 2007 sous win 7, je devrais fermer la boutique); les clients sous access <=2007 et ne savent de plus pas lire les .accdb/r,
    * Les autres formats ne sont pas testés,
    * J'ai UN installshield qui récupère les données clients et installe l'application qui a le même nom .mdb pour tout le monde,
    * Il arrive (panne) qu'un client repasse sa db sur un ancien pc (si c'est un accdb/r il ne passe pas sous les "vieux" access).


    Merci,
    Alain Bourgeois

    jeudi 24 mars 2011 22:54
  • Bonjour,

     

    Bien que je sois contre l'usage des fonctions de domaine (lenteur, fiabilité...), il semble que la méthode dont vous usez reste correcte.

     

    Toutefois, il serait bon de préciser que la DLL "beidlibaxctrl.dll" qui est requise doit voir sa référence décochée pour tester vos exemples. Du peu que j'ai pu lire sur le Web, cette DLL est exploitée pour lire les carte VITAL ?

     

    Cela m'amène tout de même à me demander comment vous déployer vos applis et comment est inscrite cette DLL sur les postes client ?

     

    Il serait fortement conseillé dans votre cas d'employer des machines virtuelles (Microsoft ou vMWare...) au regard des solutions que vous distribuez à des destinataires dont les versions sont hétérogènes.

    Comment pouvez-vous être sûr que votre appli tourne avec le Runtime si le poste est pourvu d’une version complète d’Access (Comment implémentez-vous le raccourci ad hoc) ?

     

    Plus précisément, lorsque qu'une application exploite des données via des formulaires qui sont pourvus de sous-formulaires qui eux-mêmes voient leurs champs alimentés par des fonctions de domaine voire des fonctions VBA qui effectuent des calcules à l'aide aussi et en parallèle de fonctions de domaine (sans gestion d'erreurs ni gestion des NULL), je ne peux que vous proposer cette piste...

     

    Vous ne pouvez pas distribuer une application développée avec une version X sous un Runtime Y sans faire de tests au préalables.

     

    Il est très difficile de vous aider dans votre situation, en fait...

     

    J'ai rédigé plusieurs articles sur le Runtime (par exemple).

    Peut-être vous seront-ils utiles.


    Argy
    lundi 28 mars 2011 09:16
    Modérateur
  • 1. Le beidlibaxctrl.dll est un ocx permettant d'accéder aux cartes d'identité belges. Il n'est pas utilisé dans les exemples mis sur le site, donc j'ai décoché la référence, recompilé et ai remis les exemples sans la référence sur le site, vous pouvez constater que ca ne change rien au problème.

    2. Comment je déploye mes applications? Réponse simple: un dossier qui copie le .mdb dans mes documents\<nom d'application>, et un batch qui lance le setup de l'installshield des ocx, puis positionne le sandbox mode et les dossiers approuvés dans la base de registres. Le problème posé n'est pas un souci d'installation, il se produit "bêtement" avec le runtime et le .mdb, et ce uniquement sous win 7 (aucun souci avec le même runtime et le même mdb sous win xp sp>=2 ou win vista sp>=1)

    3. 90% de mes clients sont sur une machine physique (et tous ceux sous win 7 et runtime, heureusement en grande minorité pour l'instant, ont le problème). Certains ont office pro, et travaillent sous access; ceux qui n'ont pas access utilisent le run-time (mais il est impossible d'avoir access et le run-time sous la même machine à ma connaissance, de toute façon le runtime n'a aucun intérêt pour ceux qui ont access). 10% de mes clients travaillent sous mac et ont acheté win 7 pro + office pme uniquement pour faire tourner l'application access dans une machine virtuelle windows (ils ont même payé deux office: le 2011 pour mac et le 2010 pour pme pour windowscar le pgme access génère aussi des lettres en word). Le problème n'est pas la machine virtuelle: il se produit aussi bien sur une machine réelle que virtuelle. Et dans les exemples fournis, il y a des soucis sans null et sans sous-formulaire. Si le souci était dans la logique, il se produirait sous vista et xp, non?

    4. Toutes mes applications sont développées en access 2003 et un .mdb compatible au format access 2000. Elles fonctionnent sous tous les environnements, excepté le runtime 2007v2 sous win 7 (alors que ca marche sous les autres windows). Mais le format de la base n'est pas en cause: convertir en accdb ne résoud rien, le problème reste entier.

    5. Très difficile d'aider?????? Il est très facile de constater que l'exemple fourni est correct niveau utilisation,marche sous vista et runtime 2007, et pas sous win 7 runtime 2007. Le bug est connu chez microsoft, un ingénieur m'a même donné le n° interne du bug: 851752.
    C'est un problème signalé, reproductible à souhait, très facilement; vous avez même des samples pour vérifier si c'est corrigé. S'ils ne vous conviennent pas, dites-moi pourquoi et je vous en fournis d'autres.
     

    Question: à quand le patch?


    Alain Bourgeois

     

     


    lundi 28 mars 2011 21:00
  • Oui, j'ai un peu exagéré sur la mention en écrivant "Très difficile d'aider"...
    Bon, je vais m'installer une version de W7 avec le RT2007 pour reproduire votre situation et peut-être de trouver la faille...

    Je reviens vers vous dès que j'ai une piste.


    Argy
    vendredi 1 avril 2011 14:21
    Modérateur
  • Bonjour,

    Désolé, pour le silence, des priorités professionnelles de production m'ont empêché de faire du support pendant tous ces jours.

    Bon, mes tests restent vains car il manque des fonctions ou des macros qui empêchent de vérifier à 100% le fonctionnement :

    • OpenFDayWorkB()
    • ChoixImp()

    Toutefois, la base Kineuro_Test.mdb présente effectivement ce que vous soulignez avec le rafraîchissement par la touche F9.

    En revanche, Kineuro_Test2.mdb fonctionne directement sans appuie sur la touche F9 et idem pour attest.mdb.

    Pourriez vous nous mettre à dispo un exemple sans appels de fonctions indisponibles ?

    Merci...


    Argy
    samedi 9 avril 2011 13:53
    Modérateur
  • Si ca peut vous faire plaisir...

    C'est fait... Mais le problème reste entier: ce ne sont pas des fonctions mais des macros appelées dans des évènements OnClick, et comme on ne doit même pas cliquer sur ces zones pour reproduire le problème ca ne change absolument rien. Ces exemples sont d'ailleurs des "morceaux" d'une (grosse) application où ces macros sont présentes et où le problème se produit (uniquement sous runtime 2007,win 7 - pas de soucis sous win vista/xp avec le même runtime 2007).

    De plus, F9 n'est pas une solution: défilez vers le bas, vous devez tout le temps recliquer sur F9.
    Et même après avoir défilé vers le bas, et fait un re-clic sur F9, passez à une autre application et revenez sur access une dizaine de minutes après. De nouveau bloqué, calculating...

    Bien à vous,
    Alain Bourgeois


    samedi 9 avril 2011 16:09
  • Humm, je suis comme la fosse. ;o)

    En fait, votre application n'est pas fiable en soi. Trop de confusions à gauche et à droite si je considére que ces bases exemples sont des extraits de votre "grosse" application...

    1 - Vous employez notamment des appels de champs de formulaires dans vos requêtes (ce qui est fort peu recommandé) et qui font référence à des champs pourvus d'espaces (ce qui est également fortement proscrit en matière de conception d'une BDD) mais pafois, non ; du coup, on ne sait plus d'où ça vient .
    => J'ai été obligé de reconstruire votre requête source pour que, ce qui devait apparaître à vos yeux comme fonctionnel, puisse effectivement tourner.

    2 - La syntaxe [Tabel.Champ] n'est pas conventionnelle. C'est [Table].[Champ] qui l'est.

    3 - Idem ici dans la requête ReqCountSéanceD :

    WHERE ((([Rendez-vous].[ID Traitement])=[ID_Traitement]) AND (([Rendez-vous].[Scéance prestée])=-1) AND (([Rendez-vous].[Date du rendez-vous])<=Date()));
    
    

    => Vous spécifiez une condition Where bien étrange : Que le champ [ID Traitement] de la table soit égale [ID_Traitement] ? Mais où est [ID_Traitement] ? Si je corrige en supprimant l'underscore, ça tourne mais à quoi ça rime d'afficher 2170 dans tous les champs "Prestés"...?
    Et puis, cette requête source est ambigue : il n'y a pas de condition WHERE dans votre DCount()... Et du coup, je ne comprends pas trop le rôle ou l'utilité de ce champ calculé :

    =CpteDom("[Scéance prestée]";"ReqCountSéanceD")
    
    

    Il m'est alors difficile de vérifier que ce qui est affiché est bon.

    Donc même si votre application semble fonctionner à partir d'Access, ce n'est pas pour autant une raison. Le constat que ça plante sur W7 RT2007 avec les problème de nom de contrôle/nom de champ est de fait parce ce que la rigueur s'intalle et votre appli ne la suit pas...

    Le Runtime est la meilleure des sources de test : elle vous ouvre des pistes de débogage comme celles que vous soulevez.
    Ici, sur ma machine, et c'est ce que je vous ai déjà spécifié, seule "kineuro_Test.mdb" se comporte de telle sorte à ce qu'il faille appuyer sur F9.

    Essayez de me faire parvenir une base dans les conditions que vous soulevez sans champs ambigus, mal nommés et tutti quantti, sans appel de champ de formulaire dans les requêtes...
    Je testerai de nouveau car dans l'état actuel des choses, je ne peux accepter d'incriminer le couple Windows 7 RT 2007 face à votre appli en regard de ce que je vous ai évoqué...

    Mes propres tests de fonctions de domaine (dont je vous rappelle que je n'emploie jamais dans mes projets) donnent des résultats satisfaisants d'un point de vue opérationnel, même en formulaire continu dans l'environnement précité


    Argy
    lundi 11 avril 2011 10:40
    Modérateur
  • Monsieur,

    1. "Vous employez notamment des appels de champs de formulaires dans vos requêtes" => C'est autorisé et cela fonctionne comme cela depuis access 2.0. D'ailleurs, quand on fait "Build..." sur une valeur de paramètre, il le propose. Même les exemples fournis avec access le font (cfr access 2000, comptoirs.mdb, requête factures (entre autres)).
    2.   "... et qui font référence à des champs pourvus d'espaces (ce qui est également fortement proscrit)":  Où ca? Ca existe et fonctionne aussi depuis access 2.0, TOUS les exemples fournis avec access utilisent d'ailleurs des espaces dans les noms de champs.
    3.  "J'ai été obligé de reconstruire votre requête source": pourquoi? Elle fonctionne bien sous tous les access, tous les windows, tous les runtimes... excepté sous runtime 2007 et win 7. Pour rappel, tous les exemples fournis fonctionnent avec le runtime 2007  sous win xp et vista, et sous office 2007 et win 7. Seul le runtime 2007 et win 7 plantent! (Même le runtime 2010 marche sous win 7, mais il a d'autres bugs pires niveau header et footer).
    4.  "La syntaxe [Tabel.Champ] n'est pas conventionnelle". D'accord avec vous, mais je n'utilise pas cette syntaxe dans les exemples. Où êtes-vous allé chercher ca?
    5. ReqCountSéanceD: ID_TRAITEMENT vient du formulaire en cours.
      Dans kineuroTest, le ControlSource de la zone Text73 est "=getresttext([ID Traitement];[DateRDZ])", où getresttext est une fonction vba, et [ID Traitement] et [DateRDZ] des valeurs de champs de l'enregistrement courant du formulaire.
      Ce qui est bizarre (car ca devrait n'avoir aucun effet), renommer la zone [ID Traitement] dans le formulaire (et pas dans la table), et dans la requête (ce que j'ai fait dans kineuro_test2), change le comportement du runtime.

      En aucun cas il n'y a ambigüité:
      • dans kineuro_test je spécifie le nom du formulaire dans le where,
      • dans kineuro_test2 je spécifie le nom de la zone du formulaire, qui est différent du nom du champs auquel il est lié.

      Si vous avez du mal à comprendre la logique, explication: il y a deux tables:
      • une table Traitements, comprenant une ligne par prescription médicale, clé primaire: [ID Traitement]. Chaque traitement a un nombre de séances [NB de Scéances] et parfois une date limite [DFin],
      • une table [Rendez-vous], comprenant une ligne par rendez-vous.

      La fonction GetRestText compte les rendez-vous prestés liés au traitement jusque la date du jour, en fonction de l'[ID traitement]. Et s'il y a une date de fin, il indique aussi le nombre de jours restant par rapport à la date en paramètre.
    6. "Et puis, cette requête source est ambigue : il n'y a pas de condition WHERE dans votre DCount()... "
      => Les where sont dans la requête, le DCount n'est pas basé sur une table mais sur une query. Pas d'ambigüité.
    7.  "Mes propres tests de fonctions de domaine (dont je vous rappelle que je n'emploie jamais dans mes projets) donnent des résultats satisfaisants d'un point de vue opérationnel, même en formulaire continu dans l'environnement précité": pouvez-vous m'envoyer un exemple? Je veux voir les "tests" que vous avez faits!
    8.  Si cette application est si merdique, veuillez me dire :
    • Quelle ligne du manuel j'ai enfreint?
    • Comment il se fait que ca marche sur tous les access, tous les windows, et que ca ne plante que sous win 7 avec runtime? Cette application fonctionne chez plus de 100 clients depuis 2001, chaque client étant indépendant avec son pc (donc tous les environnements sont représentés)?

    


    Alain Bourgeois
    lundi 11 avril 2011 19:59
  • Vous avez pris la mouche ;o)

    Ce n'est pas parce que Microsoft fournit des exemples qu'il faut les suivre comme une règle idéale. Et puis, rien ne garantie que Microsoft est l'auteur de ces exemples. Il existe des conventions typographiques et il est bon de les suivre.

     

    Ne me faîte pas dire ce que je n'ai pas dit...

    Je n'ai jamais écrit que les espaces étaient incompatibles avec le Runtime ou avec Access.

    Le simple fait d'avoir à "crocheter" des occurences pour les délimiter est pour ma part une contrainte non rencontrée quand on respecte la convention typographique MajusculeminusculeMotEntier pour le nom des objets, quels qu'ils soient.

    Essayez de nommer une variable avec un espace, vous aurez un retour conséquent.

     

    Citation : Où êtes-vous allé chercher ca?

    ici, dans votre champ "NomPatient" qui est égal à =SupprEspace([Patients.NomPatient] & " " & [Patients.Prénom])

     

    Citation : pourquoi? Elle fonctionne bien sous tous les access?

    Voici votre requête :

    SELECT DISTINCTROW [Rendez-vous].[ID Traitement], [Rendez-vous].[Scéance prestée], [Rendez-vous].[Date du rendez-vous]
    
    FROM [Rendez-vous]
    
    WHERE ((([Rendez-vous].[ID Traitement])=[ID_Traitement]) AND (([Rendez-vous].[Scéance prestée])=-1) AND (([Rendez-vous].[Date du rendez-vous])<=Date()));

     

     

    Je me suis permis de vous écrire cela dans la vision professionnelle que je possède.

    J'ai une connaissance accrue du déploiement Access (j'ai écris 4 articles sur le sujet) ; je ne suis pas du genre à tenter de solutionner un problème pour le vent histoire d'écrire "iou iuo, chui là !!!", mon but principal est de faire en sorte que les membres du forum pour qui je prends l'initiative de répondre soient satisfaits. S'ils se fâchent, je laisse la main.

     

    Votre façon de construire n'est pas mauvaise en soi mais elle ; ce que je reproche de prime à bord aux fonctions de domaine, c'est leur lenteur, leur lourdeur et le fait qu'elles renvoient NULL en cas de non correspondance. D'ailleurs vous avez du vous en apercevoir puisque votre propre fonction est concaténée à une valeur vbNullString pour éviter de renvoyer l'erreur 94 dans votre bloc If.

    Quant au fait d'employer des champs de formulaire dans les requêtes n'est pas une bonne chose mais il s'avère que ça rend bien service.

    Imaginez que vous ayez à migrer votre application en un véritable projet, vous seriez confronté à une impossibilité de transposer cela avec les moyens que vous employez. Ce mode de création de base de données reste pratique pour les petites applis locales à usage individuel.

     

    Désolé si je vous ai offusqué.


    Argy

    mardi 12 avril 2011 13:43
    Modérateur
  • Et bien pour quelqu'un qui demande de l'aide, vous n'êtes pas triste !

    Il faut savoir, Mr Bourgeois, qu'il y a des recommandations qui vont à l'encontre des exemples de Microsoft.  Et comme je ne suis pas MVP, je peux critiquer sans état d'âme : À jeter !
    Cela commence déjà par éviter les espaces dans les noms d'objets, et aussi de les préfixer.
    Faire référence à un champ dans un formulaire est très souple et agréable d'utilisation.  MAIS cela m'a posé deux déconvenues dont une très majeure et critique :
    1/ (mineure) Dans un formulaire, la source (requête) d'une liste déroulante dépend d'une autre. Problème : la requête est enregistrée en texte français avec "[Formulaire]....".  Mais en Flandre, "Formulaire" n'est pas "Formulaire" ni même "Formulier" mais "Forms".  Où est le temps des token ?...  (J'ose aussi dire que le français Jack AllGood [Jacques Toubon] a été une catastrophe)
    2/ (majeure) Migration vers SQL SERVER (par exemple pour des raisons de sécurité).  Une requête avec comme critère une zone de formulaire est impossible : la requête est exécutée par le serveur et ne "voit" pas le formulaire qui est chez le client.  Et alors là, bonjour la reprogrammation bien lourde...

    Cdt,
    Blaise

    <Alain Bourgeois> a écrit dans le message de news: efaab857-33aa-4c04-8730-ebdfcf8920a7@communitybridge.codeplex.com...



    Monsieur,

    mardi 12 avril 2011 16:11
  • Monsieur,

    1. "Le simple fait d'avoir à "crocheter" des occurences pour les délimiter est pour ma part une contrainte non rencontrée quand on respecte la convention typographique MajusculeminusculeMotEntier pour le nom des objets, quels qu'ils soient."=> Cette variable a un espace depuis plus de 10 ans, est crochetée partour, et ne pose souci que sous la combinaison win 7/ runtime 2007.

    2. "Citation : Où êtes-vous allé chercher ca?

    ici, dans votre champ "NomPatient" qui est égal à =SupprEspace([Patients.NomPatient] & " " & [Patients.Prénom])"

    => Oui, et je le revendique: [Patients].[NomPatient] ne marchera pas dans ce formulaire (vous pouvez le vérifier). La source du formulaire est une requête dont deux des colonnes portent les noms Patients.NomPatient, Patients.Prénom.

    

    3. Les dlookup et dcount ne sont pas en cause, je les ai remplacés par des recordset, il n'y a aucun changement dans les temps de réponse. Et ce n'est pas lent du tout: mon appli access a été comparée à 10 autres applications du marché (vb, windev, delphi, ...) et elle est  20% plus rapide que la plus rapide des autres(en usage monoposte pour les scénarios testés). Vous pouvez lancer ces applications dans un environnement où ca tourne (hors win 7 OU hors run-time), vous verrez que le résultat est immédiat.

     

    4. "D'ailleurs vous avez du vous en apercevoir puisque votre propre fonction est concaténée à une valeur vbNullString pour éviter de renvoyer l'erreur 94 dans votre bloc If."

    Ce n'est pas un problème, ni pour une raison de performance. Cette méthode renvoye un string, donc il est logique de renvoyer un string au cas où c'est NULL (car dans la vraie appli il y a en plus un formattage conditionnel sur la zone).

    

    5. Cette application est un vrai projet: 140 tables, 270 query, 260 formlaires, 120 états, 940 macros et 70 modules, tantôt sur un seul poste, tantôt partagé par 4/5 personnes. Comme l'application est en access et les données aussi, il n'y a aucune raison de ne pas profiter des facilités d'access, j'ai du mal à suivre votre raisonnement.

    

    6. "mon but principal est de faire en sorte que les membres du forum pour qui je prends l'initiative de répondre soient satisfaits": désolé si j'ai l'impression d'être un peu rude, mais  j'ai de plus en plus l'impression d'avoir des réponses de "débutants": le problème est gros comme le nez au milieu du visage.

    Je m'explique: vous prenez word 2000. Vous l'installez sous win '98, win 2K, win Xp, win vista: ca marche. Si ca ne marche pas sous win 7, en suivant votre raisonnement, c'est la faute à word. Je ne suis pas d'accord, c'est une incompatibilité.

    Dans ce cas bien précis c'est ce qui se passe: une appli qui fonctionne partout sauf dans la combinaison (win 7, runtime 2007), le problème n'est pas dans l'appli.

    Si le problème était dans la logique, il planterait avec le runtime et un autre windows aussi. Et si le problème est une incompatibilité (ce dont je suis sur), c'est d'autant plus déplorable: tout nouveau pc est équipé de win 7 et aucun runtime (ni 2007 ni 2010 ne fonctionnent, mais avec des "incompatibilités" différentes). Je dis quoi à mes clients?

    La moindre des choses quand microsoft sort un nouveau windows, serait de vérifier son fonctionnement avec ses propres applications, ce qu'ils ne font pas: j'ai eu exactement le même souci il y a 3 ans avec vista. Le souci a été résolu par?  Je vous le donne en mille: le Service Pack 1 de vista (pas celui de access).

    

    A ce train, chaque fois que ms sort un nouvel OS, je dois arrêter de vendre pendant un an (ce que j'ai fait actuellement: campagnes de pubs stoppées, ainsi que les démos). C'est scandaleux. A mon avis, fin de l'année, je réécrirai ca en joomla / php, mais microsoft fait un très mauvais calcul (leur déclin coincide avec le départ de Bill Gates et je me demande s'ils seront encore là dans 5 ans).

    

     


    Alain Bourgeois
    mardi 12 avril 2011 18:19
  • Monsieur,

    Concernant ces inconvenues:

    1/ Solution: Ne pas utiliser access Français. J'ai acheté un office developer 2000 (y a longtemps) en français, ca a été ma plus grosse erreur. Après je n'ai acheté en Anglais, et depuis toutes mes versions d'office sont en anglais (et il possède même un dictionnaire français). C'est obligatoire dans un pays qui a 3 langues officielles. Cette inconvenue est même majeure vous recevez une base de données "flamande". J'ai même vu dans un access 2007 français (avant service pack) le champs [Nom] ne comprenant pas la valeur du champs de la table attachée, mais le nom de l'état sur lequel la zone se trouve. (Heureusement, je n'ai pas encore essayé de mettre une zone [Name] dans mes tables).

    2. La question ne se pose pas dans mon cas: 90% de mes clients travaillent sur un seul pc, certains ont 3 ou 4 PC (avec des tables attachées vers un des pc's), dont ils sont de toute façon administrateurs. SQL server est "un bazooka" pour une telle utilisation, on ne me l'a jamais demandé. Bien que je ne l'aie jamais fait, je suis étonné de ce que vous dites: même si la requête est exécutée par le serveur, c'est le client (qui connait les paramètres) qui l'envoye. Enfin quoi qu'il en soit ca ne s'applique pas...

     


     

    Alain Bourgeois

    PS: je ne demande pas de l'aide, je demande un patch (et pas un patch de mon application), il y a une nuance importante.


    mardi 12 avril 2011 18:31
  • Nommer un champ "Nom" ou "Name" est identique à ceux qui emploient l'occurrence "Date" pour un champ du même nom !
    Il ne faut pas abuser... En anglais, Nom et Prénom s'écrivent LastName et FirstName pour une table de personnes donc aucun risque de conflit et de plus, qui de part leur syntaxe respective, définissent vraiment ce qu'ils ciblent. Alors que Nom ? Nom de quoi ? Si vous employez l'occurence Nom dans chaque table par besoin, vous aurez le message fatal exigeant l'alias de la table source propre à la conception de requêtes.

    Quand je vous écris qu'il y a des conventions typographiques c'est qu'il a des personnes comme qui donnent de leur temps pour écrire des choses utliles pour ceux qui veulent se donner la peine de ne pas avoir de galère au fur et à mesure que les années passent.

    Les mots réservés sont comme leurs noms l'indiquent "réservés". Si vous tenez à nommer des objets avec des noms de propriétés ou de méthodes, c'est votre droit mais vous ne pouvez pas incriminer l'application comme n'étant pas à la hauteur d'accepter cela.
    Mais, n'envenimons pas ce paragraphe, il sort du sujet.

     "PS: je ne demande pas de l'aide, je demande un patch (et pas un patch de mon application), il y a une nuance importante."

    Eh bien dans ce cas, il faut vous adresser au Support Micorosoft  : 0825.827.829

    Vous semblez si sûr de vous que je ne pense pas être en mesure d'ajouter quoi que ce soit...

    Salutations.


    Argy
    • Proposé comme réponse cdzsys mercredi 20 avril 2011 12:32
    • Non proposé comme réponse cdzsys mercredi 20 avril 2011 12:32
    mercredi 13 avril 2011 13:17
    Modérateur
  • Pour info, c'est bien un bug, et il y a même un patch (enfin!) (office-kb2475893-fullfile-x86-glb.exe).
    Alain Bourgeois
    samedi 30 avril 2011 17:26
  • Merci pour votre retour...

    Toutefois, la page concernée ne reflète pas vraiment votre problématique d'un point de vue contenu mais tant mieux si votre problème est résolu.


    Argy
    lundi 2 mai 2011 10:35
    Modérateur
  • Ce correctif résoud exactement le premier problème mentionné plus haut, à savoir que sous win 7 et access 2007, la barre d'état dans Access 2007 affiche un message «Calcul... » et les champs calculés restent vides. Si vous regardez les print screen du problème 1, c'est exactement ca.


    Alain Bourgeois
    lundi 2 mai 2011 20:48