2009-12-17 6 views
0

Mon client a une application Access (2000) que nous n'avons pas écrite et nous n'avons pas accès à la MDB (c'est un MDE). L'une des fonctions est de créer un rapport de bordereau d'expédition. Il n'y a pas d'option pour prévisualiser, seulement imprimer ou enregistrer dans un fichier.Impression d'un rapport Access et de l'étrangeté de la décimale

Il y a un champ qui représente un poids; c'est un champ double. Sur une machine autonome, il imprime correctement, mais lors de l'impression via les services Terminal Server, il affiche tous les zéros. Cependant, l'impression au format XPS nous a permis de voir qu'il formait le nombre à une vingtaine de décimales, ce qui me suggère que sur la machine autonome, il pourrait faire la même chose mais aligner le champ à gauche, mais aligner à droite (et donc afficher uniquement les zéros) via les services Terminal Server. Pour ce que ça vaut, je n'ai rien à voir avec ça, mais notre gars du réseau me l'a apporté. Je peux obtenir plus d'informations si nécessaire. Des idées sur ce qui pourrait causer cela et comment y remédier?

Répondre

0

Il est possible que l'imprimante par défaut sur le serveur formate le rapport différemment. Une situation similaire se produit avec Crystal .NET pour les personnes de notre boutique qui ont des imprimantes par défaut différentes - parfois, les éléments proches de la marge ne s'affichent pas, parfois ils s'arrêtent, parfois ils vont bien. Si possible, remplacez l'imprimante par défaut du serveur Terminal Server par la même imprimante que sur la "machine autonome", en tant que test.

1

La seule solution possible est le formatage correct du champ et qui nécessite le code source MDB. Désolé, mais c'est la seule vraie solution.

+0

... Et pendant qu'ils sont là, ils devraient changer le type de données en 'DECIMAL' avec les valeurs appropriées pour l'échelle et la précision. – onedaywhen

+0

Vous êtes au courant des bogues avec le type décimal Jet lorsqu'il est utilisé dans Access, non? Tri incorrect avec les champs décimaux: http://allenbrowne.com/bug-08.html. Je semble me rappeler que cela a été corrigé dans A2007, mais je ne trouve aucune preuve de ce trolling la base de connaissances, et Allen Browne garde au-dessus de ces choses, donc s'il ne le mentionne pas, cela doit signifier que je Je me trompe. –

+0

"Vous connaissez les bogues avec le type décimal Jet lorsqu'ils sont utilisés dans Access, n'est-ce pas?" - Je suis au courant d'un bug, étant le bug d'ordre de tri négatif. Cela a en effet été corrigé dans ACE 2007. Je crois qu'Allen Browne reconnaît le bug ici: http://allenbrowne.com/tips.html: "Tri incorrect (champs décimaux) Access 2000 sur [sic] (partiellement corrigé en 2007)" . – onedaywhen

0

J'ai essayé de changer l'imprimante par défaut en vain. La seule imprimante actuellement disponible est une imprimante partagée vers un système qui imprime correctement le bordereau de prélèvement sur la machine autonome.

Il peut être possible d'accéder à la source après tout. Pouvez-vous penser à une raison pour laquelle cela pourrait fonctionner dans un environnement autonome (sur xp) et non dans TS 2003? Merci pour tout commentaire.

+0

Appliquez un format fixe au champ sur le rapport, alors, et vous ne devriez pas avoir le problème. Cela ne ressemble pas vraiment au type de problème d'imprimante que j'ai rencontré, qui présente généralement un ensemble différent de symptômes (par exemple, le champ s'imprime entièrement en blanc sur les pilotes d'imprimante défectueux). –