Seite einrichten unterschiedlich in MDB und MDE
Frank Lauer
Ich habe verschiedene Berichte in A97 erstellt. Die Anwender soll jedoch die
Möglichkeit haben via 'Seite einrichten...' dauerhaft einen anderen Drucker
oder weitere Druckeinstellungen einzustellen.
Solange die Anwendung in einer MDB läuft, lässt sich das auch problemlos
dauerhaft einstellen. Läuft die Anwendung jedoch in einer MDE sind die
geänderten Einstellungen jedesmals weg, wenn man den Bericht geschlossen
hat.
Wie lässt sich das ändern ? Danke für Tips.
Gruss, Frank
Michael Storchmann
> Solange die Anwendung in einer MDB läuft, lässt sich das auch problemlos
> dauerhaft einstellen. Läuft die Anwendung jedoch in einer MDE sind die
> geänderten Einstellungen jedesmals weg, wenn man den Bericht geschlossen
> hat.
>
> Wie lässt sich das ändern ? Danke für Tips.
In einer mde meines Wissens gar nicht. Damit die Druckereinstellungen
permanent gespeichert werden, muß der Bericht im Entwurfsmodus geöffnet
werden können, auch wenn der Anwender das in dem Moment der
Seiteneinrichtung nicht explizit tut. Blöde ist dass :-(
Du könntest über die MDE eine MDB drüberstülpen (umgekehrt geht
es nicht). Die MDB besteht dann nur aus Berichten, einer Autoexec,
für die Berichte erforderliche Abfragen
und einer Startroutine, die wiederum die Initialisierungsroutine
der MDE aufruft. Die MDB muß also die MDE als Bibliothek
eingebunden haben. Wenn die MDE einen Bericht öffnen will,
dieser aber gar nicht in der MDE existiert, wird der Bericht
in der MDB gesucht und geöffnet. MDB und MDE sollten
die gleichen Tabellen eingebunden haben. Ferner sollte
man in der MDE alle CurrentDB-Zuweisungen durch
CodeDB ersetzen.
Viel Arbeit :-)
Bye, Michael
Klaus Oberdalhoff
> Ich habe verschiedene Berichte in A97 erstellt. Die Anwender soll jedoch
die
> Möglichkeit haben via 'Seite einrichten...' dauerhaft einen anderen
Drucker
> oder weitere Druckeinstellungen einzustellen.
hole dir mal die Datei obddruck.zip von www.accessware.de damit sollte es
gehen ...
--
mfg
Klaus KO...@gmx.de
PS:Tips und Tricks zu ACCESS 97 (** KnowHow-MDB ** Ver 3.0 - 30.9.1999)
unter http://www.accessware.de/
Access-FAQ bei: http://www.donkarl.com/AccessFAQ.htm
Frank Lauer
Dass ist aber crazy, dass man die Einstellungen nur im Entwurfsmodus ändern
kann :-((((
Ich bin ja nicht verrückt und lasse simple ;-) Anwender im E-Modus an meinen
mühsam gebastelten Berichten herumwerkeln.
Das mit der zweiten MDB scheint wirklich viel Arbeit zu sein und ist mir
auch sonst nicht so sympathisch. Trotzdem danke für Deine Antwort.
Falls jemand noch andere Lösungsansätze anbieten möchte - nur keine
Hemmungen.
Danke, Frank
Michael Storchmann <mstor...@cityweb.de> schrieb in im Newsbeitrag:
86t5ff$10p$1...@news.cityweb.de...
>
> In einer mde meines Wissens gar nicht. Damit die Druckereinstellungen
> permanent gespeichert werden, muß der Bericht im Entwurfsmodus geöffnet
> werden können, auch wenn der Anwender das in dem Moment der
> Seiteneinrichtung nicht explizit tut. Blöde ist dass :-(
>
> ...................
> Viel Arbeit :-)
>
Frank Lauer
Deine Datei hat sehr interessante API Aufrufe. Sie stellen aber letztendlich
den Windows Standart Drucker um. Das ist es aber auch nicht was ich möchte.
Ich habe verschiedene Berichte. Jedem Bericht sollte individuell ein Drucker
und Einstellungen zugeordnet werden können. Da gibt es z.B. Berichte die nur
weggefaxt werden sollen (Drucker WinFax) oder nur intern verwendet werden
(Laser 300dpi) oder irgendwas Buntes (InkJet 1200dpi).
Jetzt könnte man natürlich vor jedem Bericht den Standartdrucker umstellen.
Das stelle ich mir aber auch nicht so einfach vor. Vor allem wenn dann noch
mehrere Berichte gleichzeitig offen sind.
Da steh ich nun, ich armer Tor, und bin so klug wie zuvor.
Gruss, Frank
Klaus Oberdalhoff <ko...@gmx.de> schrieb in im Newsbeitrag:
86v1c3$ij6$6...@news10.roka.net...
> Hi,
Klaus Oberdalhoff
> Deine Datei hat sehr interessante API Aufrufe. Sie stellen aber
letztendlich
> den Windows Standart Drucker um. Das ist es aber auch nicht was ich
möchte.
Jupp, das ist richtig.
ich dachte eigentlich mehr, dass du in diesem Falle einfach
a) Drucker alt merken
b) Neuen Drucker als Standarddrucker
c) Drucken
d) Alten Drucker als Standarddrucker
diese Sequenz a) - d) in eine Function schmeisst, und dann das Formular über
diese Funktion druckst ...
nur so als Idee ...
Urs Villiger
Dieses Manko in der MDE-Datei ist der Grund, dass ich immer MDB ausliefere. Du
kannst jedoch die Zugriffsrechte so steuern, dass sowohl simple wie
qualifizierte NutzerInnen nichts herumwerkeln können.
Ein Problem mit Verweisen auf andere DB's ist, dass Du aus diesen heraus nicht
mehr auf den VBA-Code der verweisenden DB zugreifen kannst.
Gruss Urs
Frank Lauer schrieb:
Christa Schwanke
> Ein Problem mit Verweisen auf andere DB's ist, dass Du aus diesen heraus
nicht
> mehr auf den VBA-Code der verweisenden DB zugreifen kannst.
Was meinst Du damit?
Funktionen in Modulen sind auf jeden Fall verfügbar.
Dabei geh' ich oft so vor:
Module werden in eine .mde ausgelagert, damit wenigstens was geschützt
wird.
Reps in eine .mdb, in der ein Verweis auf die Modul.mde gesetzt wird.
Das hat den Vorteil, dass ich die Reps anwenderspezifisch einrichten kann
und
dies nicht in meiner Versionsverwaltung berücksichtigen muss.
Wichtig ist sicherzustellen, dass überall dieselben Daten eingebunden
sind.
Die eigentliche Anwendung ist eine .mdb, die einen Verweis auf die modul.mde
und die rep.mdb enthält.
Modul.mde und Rep.mdb müssen ins jeweilige Systemverzeichnis, damit
die Anwendung die Verweise wieder findet.
Sobald sich jetzt allerdings die modul.mde ändert (Oder die Verweise drin
zerschossen
sind) muss ich halt erst die rep.mdb und anschließend die anwendung.mdb beim
Anwender neu kompilieren bzw. schlimmstenfalls erst die modul.mde beim
Anwender neu erstellen.
Aber insgesamt ist's mir immer noch lieber, als die einzelnen
Report-Versionen
incl. anwenderabhängiger Drucker bei mir zu verwalten.
Mit automatischer Lösung ist mir dazu noch absolut nix eingefallen. :-(
Die bessere Variante wär's wahrscheinlich, die Rep.mdb über das Application-
Object aufzurufen - dann muss nicht neu kompiliert werden.
Allerdings wird damit eine zusätzliche Instanz von Access geöffnet - was
auch
nicht jeder Anwender-Rechner mit vernünftigen Laufzeiten aushält.
Und die Verweis-Problematik bleibt eh' immer.
Hat jemand noch eine bessere Idee?
Viele Grüsse,
Christa
Urs Villiger
Christa Schwanke schrieb:
> Hallo Urs,
>
> > Ein Problem mit Verweisen auf andere DB's ist, dass Du aus diesen heraus
> nicht
> > mehr auf den VBA-Code der verweisenden DB zugreifen kannst.
> Was meinst Du damit?
> Funktionen in Modulen sind auf jeden Fall verfügbar.
>
salü christa
was ich meine ist, dass wenn Du nur die Berichte auslagerst, innerhalb der
Berichtsmodule nicht auf die Module in der Haupt-DB zugegriffen werden kann. Mit
Deinem Verfahren sollte dies möglich sein.
Gruss Urs
Michael Storchmann
> Die eigentliche Anwendung ist eine .mdb, die einen Verweis auf die modul.mde
> und die rep.mdb enthält.
Dann kann doch aber die modul.mde keinen Report der rep.mdb
öffnen, oder?
> Sobald sich jetzt allerdings die modul.mde ändert (Oder die Verweise drin
> zerschossen
> sind) muss ich halt erst die rep.mdb und anschließend die anwendung.mdb beim
> Anwender neu kompilieren
Auch nur wenn sich nur die Modul.mde ändert? Das Kompilieren der
Anwendung.mde durfte bei einer neuen Modul.mde so
schnell gehen, daß man dies kaum explizit tun muß. Eh problematisch,
wenn der Kunde nur eine Runtime-Version installiert hat.
> Die bessere Variante wär's wahrscheinlich, die Rep.mdb über das Application-
> Object aufzurufen
Kann man da eigentlich bei Bedarf eine explizite Workgroup plus
User plus Passwort übergeben?
> Und die Verweis-Problematik bleibt eh' immer.
Die hatte ich komischerweise nie (außer 1 vermuteten
Fall), obwohl meine Hauptanwendung auf weit >300
Rechner installiert ist. Steht eigentlich genau fest,
wenn Access die Verweise zerschießt?
Ach ja, eine Lösung habe ich natürlich: Eine Petition
bei Microsoft einreichen :-) Seit Access 2.0 verstehe
ich nicht, warum es mit expliziter Druckerangabe
zur Laufzeit so problematisch ist...
Bye, Michael
Christa Schwanke
> > Die eigentliche Anwendung ist eine .mdb, die einen Verweis auf die
modul.mde
> > und die rep.mdb enthält.
> Dann kann doch aber die modul.mde keinen Report der rep.mdb
> öffnen, oder?
Braucht sie nicht - das macht die Anwendung.mdb.
> > Sobald sich jetzt allerdings die modul.mde ändert (Oder die Verweise
drin
> > zerschossen
> > sind) muss ich halt erst die rep.mdb und anschließend die anwendung.mdb
beim
> > Anwender neu kompilieren
> Auch nur wenn sich nur die Modul.mde ändert?
Ja. Selbst wenn sich nur das Erstelldatum der .mde ändert.
>Das Kompilieren der
> Anwendung.mde durfte bei einer neuen Modul.mde so
> schnell gehen, daß man dies kaum explizit tun muß. Eh problematisch,
> wenn der Kunde nur eine Runtime-Version installiert hat.
Stimmt. Ich muss wenigstens auf einem Rechner Access haben.
Ansonsten sollten die Rechner möglichst einheitlich installiert sein.
Außerdem liegt das Problem liegt auch darin, dass es in der richtigen
Reihenfolge
passieren muss.
Da ja die Anwendung.mdb einen Verweis auf die rep.mdb enthält, muss
erst die rep.mdb und dann die Anwendung.mdb kompiliert werden.
Irgendwie hab' ich die Hoffnung, dass das unter A00 besser geworden ist,
aber so ganz im klaren bin ich mir da auch noch nicht.
> > Die bessere Variante wär's wahrscheinlich, die Rep.mdb über das
Application-
> > Object aufzurufen
> Kann man da eigentlich bei Bedarf eine explizite Workgroup plus
> User plus Passwort übergeben?
Hab' ich noch nie probiert, weil's mir eben zuviel Speicherplatz kostet.
> > Und die Verweis-Problematik bleibt eh' immer.
> Die hatte ich komischerweise nie (außer 1 vermuteten
> Fall), obwohl meine Hauptanwendung auf weit >300
> Rechner installiert ist. Steht eigentlich genau fest,
> wenn Access die Verweise zerschießt?
Nachdem ich grundsätzlich immer wenigstens einen Verweis auf
Word drinhabe - sobald ein anderes SP installiert ist.
Naja - stimmt auch nicht so ganz.
Ich verteile inzwischen mit SP1 - da passiert nix, wenn SP2 installiert
ist - umgekehrt schon.
Oder Word ist nicht vollständig installiert - damit kann ich dann nicht
auf Word-Basic-Funktionen zurückgreifen -> es scheppert schon
wieder.
Bei den Funktionen, mit denen ich arbeite, nützt mir auch Late Binding
nix.
Ansonsten kann's halt bei jedem Verweis passieren, wenn irgendeine
Anwendung eine andere Komponente installiert.
Und nachdem ja jeder rumschreibt, wie er will...
Richtig interessant ist's jetzt mit den A00-Installationen.
Ich hab's noch nie geschafft, eine A00-App ohne Verweis-Problem
zu installieren. :-(
> Ach ja, eine Lösung habe ich natürlich: Eine Petition
> bei Microsoft einreichen :-) Seit Access 2.0 verstehe
> ich nicht, warum es mit expliziter Druckerangabe
> zur Laufzeit so problematisch ist...
Tja - die Idee scheint mir wirklich die erfolgversprechenste zu sein! ;-)
Viele Grüsse,
Christa
Michael Storchmann
> Nachdem ich grundsätzlich immer wenigstens einen Verweis auf
> Word drinhabe - sobald ein anderes SP installiert ist.
Das ist es vielleicht. Verweise auf Word verwende ich nie -
ich bevorzuge lieber das späte Binden von Word.
> Bei den Funktionen, mit denen ich arbeite, nützt mir auch Late Binding
> nix.
?? Was kann man bei Early Binding denn mehr tun als beim
späten Binden?
> Ich hab's noch nie geschafft, eine A00-App ohne Verweis-Problem
> zu installieren. :-(
Ich versuchs erst gar nicht. Bei Office ist es genau das selbe
wie bei NT-Service-Packs und bei Star Trek-Kinofilme: Jede(r)/(s)
Zweite ist ne Pleite :-))
Bye, Michael
Frank Lauer
Da es offenbar keine 'einfache' Lösung für das Druckerproblem gibt, habe ich
mich entschlossen, statt der MDE die MDB freizugeben. Das ist nicht so
schlimm, da z.Z. die Anwendung nur hausintern gebraucht wird.
Gibt es da eigentlich wesentliche Performanceunterschiede zwischen MDE und
MDE ?
Und wie war das mit der linken Shifttaste nochmals, lässt sich das beim
Aufstarten unterbinden ? Oder was kann ich noch tun, damit nicht gleich
jedermann in meinen Sourcecode hineinschaut.
Gruss, Frank
Karl Donaubauer
> Da es offenbar keine 'einfache' Lösung für das Druckerproblem gibt, habe ich
> mich entschlossen, statt der MDE die MDB freizugeben. Das ist nicht so
> schlimm, da z.Z. die Anwendung nur hausintern gebraucht wird.
>
> Gibt es da eigentlich wesentliche Performanceunterschiede zwischen MDE und
> MDE ?
Naa, eigentlich nicht. Man könnte sogar behaupten, dass MDEs sich i.d.R.
genauso verhalten wie MDEs.
> Und wie war das mit der linken Shifttaste nochmals, lässt sich das beim
> Aufstarten unterbinden ? Oder was kann ich noch tun, damit nicht gleich
> jedermann in meinen Sourcecode hineinschaut.
FAQ 1.5 Verhindern der Shift-Taste beim Start
(Könnte sogar auch für die rechte Shifttaste funktionieren.)
--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com NEUE ADRESSE !
APP: http://www.AccessProfiPool.com
Michael Storchmann
> > Gibt es da eigentlich wesentliche Performanceunterschiede zwischen MDE und
> > MDE ?
>
> Naa, eigentlich nicht. Man könnte sogar behaupten, dass MDEs sich i.d.R.
> genauso verhalten wie MDEs.
Da kann wohl niemand auf der Welt widersprechen, da diese
Aussage formal vollendet ist (außer dem "i.d.R.) :-)
Eine MDB kann schonmal - aus welchen Gründen auch immer,
in einem dekompilierten Zustand übergehen, eine MDE nicht.
Vielleicht ist das auch eine Begründung, warum man zerschossene
Verweise in einer mde nicht mehr reparieren kann: eine MDB
dürfte in diesem Zustand dekompiliert sein, was ja bei einer
mde nicht möglich ist.
Bye, Michael
Peter Steimann
"Michael Storchmann" <mstor...@cityweb.de> schrieb im Newsbeitrag
news:876nkf$82j$2...@news.cityweb.de...
> Karl Donaubauer <ad...@donkarl.com> schrieb:
>
> > > Gibt es da eigentlich wesentliche Performanceunterschiede zwischen MDE
und
> > > MDE ?
> >
> > Naa, eigentlich nicht. Man könnte sogar behaupten, dass MDEs sich i.d.R.
> > genauso verhalten wie MDEs.
>
grundsatz: je kleiner die db, je schneller. meine mde schrumpft um ca 30%
gegenüber einer mdb. allerdings gilt auch: je schneller der rechner, je
kleiner der unterschied.
> Eine MDB kann schonmal - aus welchen Gründen auch immer,
> in einem dekompilierten Zustand übergehen, eine MDE nicht.
das ist ein ganz wesentlicher punkt!
>
> Vielleicht ist das auch eine Begründung, warum man zerschossene
> Verweise in einer mde nicht mehr reparieren kann: eine MDB
> dürfte in diesem Zustand dekompiliert sein, was ja bei einer
> mde nicht möglich ist.
hmm. trotzdem lassen sich brokenreferences via code aus einer mde entfernen,
aber imo keine neuen anlegen. ich geh mal davon aus, dass eine mde nur zu
95% "kompiliert" ist.
gruss
peter
Michael Storchmann
> Jetzt versuche ich einmal anhand der hier gefunden Tips die Berichte
> auszulagern.
Aber wenn Du einen Bericht ändern oder weitere hinzufügen mußt,
hast Du wieder ein Problem. Du mußst die Druckerauswahl
irgendwo anders speichern.
> Habe allerding noch kein Wort verstanden wie das gehen soll ;-)
Mit anderen Worten: meine pädagogische Kompetenz ist gleich
null :) Ich weiß schon, warum ich Schulungen vermeide...
Bye, Michael