La séparation de la base de données d'accès peut-elle causer des problèmes avec l'imprimante et les rapports?

Nous avons une installation dans laquelle nos utilisateurs entrent dans la base de données d'accès à l'aide de MS Access 2003 via la connexion RDP. Base de données Backend (

.mdb) disponible pour nos utilisateurs avec leur base de données d'interface externe (

.mde) et protégé par la base de données de sécurité (* .mdw).

Premièrement, l'utilisateur entre dans ses machines à l'aide d'un profil en mouvement. Ensuite, ils cliquent sur le fichier de connexion rdp sur le bureau et entrez le serveur distant à travers RDP, où ils utilisent MS Access comme une coquille; Ils n'ont aucun accès à aucune des fonctions explorer.exe, Par exemple, le menu "Démarrer".

La base de données dans laquelle ils entrent ressemble davantage à une application et fournit des fonctionnalités pour la saisie de données, la demande de données et le lancement de rapports dans le menu basé sur le formulaire. Tout a très bien fonctionné jusqu'à ce que nous divisions la base de données, car sa taille approchait 2 Gb

Nous avons déplacé les données de salaire dans une section distincte, base de données avec le même nom sur un autre dossier, les deux sont sur le serveur. Dans cette nouvelle section de base de données, seules deux tables ont été déplacées et elles ont été reliées comme des tables externes dans une nouvelle section.

Maintenant, bien que après la séparation, tout fonctionne bien en termes de données, un nouveau problème se pose lorsque nos utilisateurs entrent dans le système à travers RDP Et ils essaient d'exécuter des rapports: le rapport n'est souvent pas affiché et que l'utilisateur voit une erreur sur un événement de clic pour le formulaire. Au début, je ne savais même pas que c'était lié à l'imprimante, car, autant que je sache, nous n'avons changé rien que les imprimantes concernées.

Confus à cause de l'erreur, j'ai parlé avec un gars qui avait déjà travaillé ici et répondit pour séparer la base de données et il m'a dit que les utilisateurs définissent leurs imprimantes par défaut (sur leurs machines locales, et non sur le serveur) sur

"une imprimante"


Microsoft XPS Document Writer

Qui n'est pas une imprimante physique du tout. Cela a permis à l'utilisateur d'afficher ses rapports, mais s'ils veulent imprimer des rapports, ils doivent aller à

File

Menu et sélectionnez

Print

, En cliquant sur l'icône Imprimer dans la barre d'outils, vous irez à

Save As...

dialogue, comme prévu lorsqu'il est utilisé

Microsoft XPS Document Writer

en tant qu'imprimante par défaut.

Facile à déterminer si l'utilisateur a un problème, car avec un curseur de vol stationnaire rapide à l'icône de l'imprimante apparaît une pointe pop-up.

(none)

Quand ils ne peuvent pas accéder à leurs rapports et la pointe pop-up

Microsoft XPS Document Writer

Quand ils peuvent voir des rapports. Si une imprimante utilisateur est définie sur une valeur sauf

Microsoft XPS Document Writer

Défaut sur leur ordinateur local, puis

(none)

toujours affiché quand ils envoient rdp Dans la base de données. Réglages RDP Configuré pour envoyer une imprimante locale au serveur.

Pour dire aux utilisateurs de le faire pour l'impression, c'était comme une raison de corriger la situation jusqu'à la recherche de la meilleure solution et une explication de la raison pour laquelle la séparation de la base de données ne permettrait pas aux utilisateurs d'imprimer ou même d'afficher des rapports d'accès à la base de données. C'est pourquoi je pose cette question.

Il convient également de noter que toutes les imprimantes en ligne sont maintenant affichées sur le serveur, alors lorsque les utilisateurs cliquent

File->Print

Pour imprimer vos rapports sur l'imprimante physique, ils doivent afficher une énorme liste d'imprimantes pour trouver votre liste déroulante. Donc, notre petite leucoplastie n'est pas idéale. Auparavant, seules les imprimantes sur l'ordinateur de l'utilisateur local sont affichées ici et toutes les imprimantes du réseau.

Mon collègue semble penser qu'il est en quelque sorte liée aux autorisations, je pense personnellement que cela est dû aux profils déplacés et aux politiques de groupe que j'ai lues.

Je ne sais vraiment pas comment le réparer ni comment il est associé à la division de la base de données.
Invité:

Babette

Confirmation de:

Access Nécessite l'imprimante par défaut avant de pouvoir ouvrir des rapports (conception / Impression / Aperçu). Il semble que votre problème soit plus dans la configuration d'imprimantes et de serveurs que dans la séparation de la base de données. J'ai également rencontré de rares cas lorsque certains pilotes d'imprimante ont entraîné une défaillance des rapports Access.

À en juger par votre description du problème, ils n'ont pas d'imprimante par défaut qui provoque une défaillance.

Vos utilisateurs sont-ils en principe général? S'ils le font, les pilotes seront installés sur le serveur et leur imprimante sera mappée, alors pourquoi ne pas leur permettre d'utiliser leur imprimante normale par défaut? Rien ne connaît votre configuration, c'est un guide aveugle.

Babette

Confirmation de:

Il semble que quelqu'un a également apporté des modifications aux paramètres publiés de l'application TS Server, contrôlant les imprimantes.

La seule façon de penser que la division de la base de données pourrait le faire serait si l'ancien MDB eu une certaine logique à limiter / Installation d'imprimantes et après la séparation, vous utiliseriez une nouvelle interface MDB, qui n'a pas la même logique. Cependant, en juger par votre description, les utilisateurs utilisent toujours le même MDB Pour votre interface externe, uniquement avec plusieurs tables qui sont maintenant des liens vers un nouveau fichier interne. MDB.

Pour répondre aux questions, connectez-vous ou registre