[AC-2010] Souci de déploiement avec 2010 [Résolu]

[naphta]

Souci de déploiement,

J’ai fait un nouveau package avec le runtime 2010, le déploiement sur 3 machines Win7 64B fonctionnent normalement les 2 suivantes sous vista 32B plantent exactement de la même façon avec l’erreur 430 au démarrage.

Après qq heures de recherche la référence qui génère le souci est msado28.tlb.
Elle n’est pas marquée manquante.

Si je fais le runtime(accdr) avec une machine XP ça tourne j'ai plus l'erreur sur les 2 vista !

Cela signifie que cela vient de la machine avec laquelle je fait accdr ! C'est une machine Win7 64B !

Que faire ? J'ai du coups stoppé le déploiement !

Merci

[naphta]

Bonjour,

Voici la seule piste découverte apparemment, du moins j'en ai l'impression le problème est connu chez microsoft et ce depuis un moment ici :

http://social.msdn.microsoft.com/For...6-34f11c6b5a13

pas de solution pour le moment.

Je me pose à nouveau la question du passage vers DAO.

a+

[argyronet]

Bonjour,

Humm, la transition 32/64 pose un réel problème qui coule en douceur mais qui soulève l'installation de nombreux correctifs...

1. As-tu mis en application ce qui est évoqué ici ?
2. Et d'ailleurs, pourquoi ADO ? Ton appli est un projet SQL Server ?

Si tu as le choix, il vaut mieux privilégier DAO.

Argy

[naphta]

Bonjour,

Petite précision les offices sont en version 32B mais pas les OS.
Je viens de vérifier les versions de fichiers par rapport au bulletin, ils collent.

Le réseau est sous SBS 2011 alors MàJ obligatoire sur toutes les bécanes tous les jours, ce nouveau SBS c'est le flicage à mort de tout ce qui est connecté même le nas.

Je suis passé sur ADO car il était question d'un passage sur SQL, projet abandonné depuis.
Le passage à DAO, c'est d'ailleurs la question que je soumets ici : dans l
depuis un archivage à résolu tous les soucis.
Je pense que je vais le faire :"DAO le retour".

a+

[naphta]

Bonjour,

Les cdo aussi posent des problèmes car ils utilisent une biblio ADO pour mettre à jour les paramètres de connexion.
J’ai tenté d’utiliser une version plus ancienne d’ADO mais là aussi plantage de l’appli.

Solution trouvée utilisation de script vbs externes.

Les solutions proposées pour éviter le souci ne fonctionnent pas, ils proposent de désinstaller le SP1 Win7 mais pour moi ce n'est pas une bonne solution.

Faudra sans doute attendre une nouvelle version d'ADO.
a+

[argyronet]

Humm, il me semble bien qu'il existe la version 64 de ces composants... Enfin d'après Microsoft.

Argy

[naphta]

Bonjour,

Je te remercie pour ton intérêt mais

Je n'ai pas Office 2010 en 64 bits mais en 32 bits
c'est l'os qui est en 64 bits et sur bon nombre de machines.

Quand je compile le runtime sur une machine 64 bits je n'ai aucun soucis sur les machines 64 bits, c'est sur les OS en 32 bits que j'ai le souci.

Ce problème est par ailleurs rencontré sur d'autres plateformes de dev.

J'ai fini la bascule en DAO, la galère
j'ai eu des soucis avec
COMDLG32.OCX remplacé par les API, il n'imprimait pas le bon nombre de page !
MSChrt20.ocx, mshflxgd.ocx, mscomct2.ocx, mscomctl.OCX aussi, la solution a été de les isoler dans un sous répertoire et de les référencer à cet endroit !

Je pense devoir me passer totalement des ActiveX, une autre galère mais là monstrueuse.

a+

[argyronet]

Quel message d'erreur reçois-tu ?
Es-tu sûr que ces composants sont inscrits ?

Argy

[naphta]

Bonjour,

Ce que j'ai fait pour aller jusqu'au bout :
J'ai fait un petit runtime avec 10 lignes de code, je cherche un enregistrement et je l'affiche dans un formulaire aucun activeX mise à part msado28.tlb.

Je compile et transfert vers un poste vista 32bits.
et là voici l'erreur :

la classe ne gère pas automation ou l'interface attendue.

a+

[argyronet]

Humm, ça sent le MDAC roussi ça...


Argy

[naphta]

Bonjour,

C'est la première chose que j'ai vérifiée, tous les composants sont à jour.
J'ai même repassé un coup d'install sur un vista au cas où !

Je te remercie encore une fois mais en fait c'est un post de mise en garde, comme l'histoire des killbit passé un moment.

Le réseau est à jour, SBS pousse toutes les MàJ vers les stations et même les MàJ non obligatoires l'admin du réseau les forces vers les PC, le problème vient de là trop de MàJ ! Il y en a tous les jours !

J'ai remonté un access 2007 sur un vieux XP recompilé l'appli pour les vista 32B.
J'attends la consolidation du passage vers DAO pour redistribuer le nouveau frontal.

Encore merci

[Depite]

Bonjour à tous,

Naphta rencontre un problème qui semble toucher pas mal de monde dont je fais partie moi-même.
Je viens d'ouvrir un peu prématurément une discussion pour demander de l'aide sur le sujet avant d'avoir remarqué ce forum et lu votre discussion qui tape en plein dans le mil!

Pour ma part voici la situation :
J'ai développé une appli de type projet sur Access 2010 en utilisant la version gratuite téléchargée sur une machine XP 32 bits sp3 à jour.

Le produit réalisé a été "compilé" en .ADE sur cette même machine et distribué sur un ensemble éthérogène de postes (Xp 32, W7 32, W7 64) et a fonctionné très bien - abstraction faite des bugs que je n'ai pas omis d'y insérer) - sur toutes les plateformes quelle que soit la version d'Office (2003, 2007, 2010) installée sur le poste.

Disposant maintenant de la verions complète d'access 2010 et d'une nouvelle machine dotée de W7 32bits je l'ai utilisée pour apporter au projet quelques améliorations. J'ai recompilé le projet que j'ai ensuite distribué et ce futr la catastrophe : seuls les PC dotés de W7 64 font tourner l'appli sans erreur; pour tous les autres erreur de compilation pour cause de rupture de référence à l'identique de ce que rencontre naphta.

Demain je reprends mon projet sur XP pour pouvoir continuer à avancer !

A part ça, je trouve regrettable de proposer un retour vers DAO même pour une appli ACCDR dans la mesure où Microsoft nous a bien arrosé d'ADO. D'autant plus que la conversion risque de représenter un travail assez monumental.

[naphta]

Bonjour,

Et Bonjour au compagnon d'infortune, Depite !

J'ai aussi tenté de dégrader vers msado25.tlb, même souci,

tout est là
http://social.msdn.microsoft.com/For...6-34f11c6b5a13

Dans la discussion plus haut ils parlent d'une mise à jour ADO qui devrait venir bientôt ...

C'est certain que le passage à ADO était, dixit n programmeurs, absolument nécessaire car DAO ne devait pas faire long feu.

Je consolide le passage de ADO vers DAO :
démarrage de l'appli plus rapide du côté DAO
liaison avec un (relink) extrêmement lent avec DAO 5 à 8mm
un peu plus de code avec DAO
pour le reste pas de diff.

je confirme ceci :
La compilation de l'appli même modifiée par access 2010 sur un XP 32B sous access 2007 rend l'appli fonctionnelle sur tous les postes.

Bon courage !

PS: Microsoft est en train de rendre beaucoup de choses inutilisables pour des raisons de sécurité et de maintenance.

[naphta]

Bonsoir,

Bonne nouvelle,
Apparemment microsoft reconnait le souci et propose une solution ici :

http://social.msdn.microsoft.com/For...7-b28928206e38

Voir le dernier post du 19/09, la solution se trouve dans la version preview de Windows 8.

A bientôt