Office: (Office 2010) Debug.Print

Hallo,
O.K., dann nenne ich das jetzt "FilterString". Denn bei nicht funzenden Filtern wird ja auch
gerne auf Debug.Print zum anschauen/testen verwiesen.

@josef
Dass das mit der Transaction zu tun hat, hatte ich ja schon in #9 vermutet, wo die gleiche
Frage schon einmal gestellt hatte.

Habe ich aber gerade gelöst. Die Transaction wird erst nach dem .CreateQueryDef gestartet.
Code:

Jetzt ist aber Schluss für heute, - gute Nacht.
gruss ekkehard

 

Moin,
So, ich denke die letzten Probleme konnte ich nun lösen.
Das Problem mit Transaction und temporärer Query (ohne Namen), und das Umschalten in die SQL-Ansicht.
Code:

Ansonsten habe ich noch kleine Veränderungen/Ergänzungen ergänzt *wink.gif*

1. den Code aus cmdSqlPruefen_Click in eine Sub SQLPruefen() ausgelagert. Da mir die Idee kam,
die erste Prüfung gleich schon Mal im Form_Open anzuschieben, - spart einen Klick, und die Info-Box ist
gleich gefüllt mit einer evtl. Fehlermeldung. Dazu habe ich

2. auch noch einen Button erstellt um auch diese in die Zwischenablage zu kopieren. Könnte auch hier den
Helferlein nützlich sein, da sie ja selten übermittelt wird von den Fragestellern. Und der Hinweis auf ein
Debug.Print Err.Description wird ja wohl auch eher auf taube Ohren treffen, wie man ja am Auslöser
dieses Threads gelesen hat *wink.gif*
Dann ist mir noch eingefallen, dass man ja nicht sicher von Einstellung "Ganzes Feld markieren" ausgehen kann, habe ich
3. das auch noch "abgefangen".

Ich hoffe nun, das da keine groben Schnitzer mehr drinne sind, und hänge die DB hier dran. Datei enthält
sowohl .MdB als auch accdb.

gruss ekkehard


Für alle, die es mal ausprobieren möchten:
- aus der .zip-Datei die passende Access-Version wählen
- das Formular "frmDebugPrint" und das Modul "mdlDebugPrint" in die eigene DB kopieren/importieren
- im eigenen Code dann sDebugPrint(varString) statt Debug.Print(varString) verwenden.
Wenn man den Code an dieser Stelle anhalten möchte, schreibt man
Code:

(danke Josef)

 

Hallo!

Deine Fehlerbehandlung in Hilfsprozeduren (ErrorTrapping-Prozeduren) ist meiner Meinung nach falsch.
Du zeigst den Fehler in einer Msgbox an und machst dann aber im Code weiter als wäre nichts passiert.
Manchmal ist keine Fehlerbehandlung besser als eine, die den Fehler übergeht.
Besser finde ich es, wenn bei Hilfprozeduren der Fehler nach oben weitergereicht wird.
Ausnahme: man will bewusst den Fehler ignorieren.

Anm.: für diese 2 Prozeduren spielt das keine Rolle, da dort kein Fehler auftreten wird. Ich erwähne das aber trotzdem, falls du diese Fehlerbehandlungs-Routine in allen deinen Prozeduren hast.


mfg
Josef

 

Hallo Josef,
Fehlerbehandlung ist eines meiner Stiefkinder. Obwohl ich schon öfters mal
versucht habe mich da einzulesen, gerade von dir gibt da ja einiges, muss ich
zugeben, auch wenn es mich beschämt, dass ich dann irgendwie doch nicht die
Motivation gefunden habe es endgültig zu verstehen und mal umzusetzen. *stupid
Der Grund ist wohl auch, dass ich keine DB für dritte erstelle, sondern nur selber
damit "arbeite".

Aber doch zumindest die Meldung anzeigt. Ich mache das wohl deshalb so, um,
wenn's dann "läuft", zu sehen an was ich vorher nicht gedacht habe, - ich bin halt
immer noch ein Anfänger. Da habe ich dann den Hinweis und kann den Code
anpassen (Fehler vermeiden) bzw. den Fehler behandeln (wenn's nicht anders
geht).

Nicht in allen. Wenn ich es mir aber nebenbei noch mal ansehe, dürften aber da,
wo sie drinsteht, auch keine Fehler mehr auftreten (hoffe ich).
Da mir aber eh noch etwas eingefallen ist, womit ich mich am WE beschäftigen
werde, kann ich das ja auch noch korrigieren.

gruss ekkehard

 

Moin,
Irgendwie kann ich es zwar nicht glauben, aber ich scheitere seit Tagen an
DoCmd.TransferDatabase
Meine Idee war, dem Tool ein Startformular zu spendieren, um die beiden
Module in eigene DB zu exportieren. Und das, wenn möglich, gleich in
beliebig viele.
Also Formular mit einem Textfeld und zwei Buttons erstellt, und diese
beiden Prozeduren geschrieben.
Code:

Dies funzt bei einigen DB, wenn ich sie einzeln aufrufe; - meint die Schleife wird nur
1x durchlaufen. Bei anderen geht es
1. gar nicht. Dabei werden die im Kommentar beschriebenen Fehler ausgelöst; oder
2. die Prozedur läuft ohne Fehler durch, aber der Export findet nicht statt.
Mit mehreren DB hintereinander geht auch gar nicht, selbst wenn eine einzeln
funktionierende darunter ist.
Alles im Einzelschritt getestet, - Array wird sauber durchlaufen, die Inhalte stimmen.
Die Exporte habe ich mit intensivster OH zustande bekommen; - habe ich da vielleicht
was entscheidendes übersehen?
Oder macht Ganze gar keinen Sinn, da man auf zu viele verschiedene Einstellungen
stösst, die den Export verhindern?

gruss ekkehard

 

Hallo!

Bevor ich darüber nachdenke, warum dein Code nicht wunschgemäß läuft:
Warum willst du die Codemodule und das Formular in jede Anwendung kopieren?
Vielleicht wäre ein Add-In praktischer. In die jeweilige Anwendung nur eine Faktory-Prozedur einfügen, die das Add-In öffnet und der Rest läuft dann im Add-In ab.

z. B.:
Code:

Im Code dann (statt dem sDebugPrint-Aufruf):
Code:

mfg
Josef

 

Hallo Josef,

Das Ganze richtet sich ja hauptsächlich an Anfänger. Und da wollte ich es natürlich
so einfach wie möglich machen.

Damit habe ich mich noch nie auseinander gesetzt, weiss also (noch) nicht, wie man das macht.
Habe aber gerade mal gesucht und ein Whitepaper von Thomas Möller gefunden.
Das werde ich mir morgen zu Gemüte führen. Mal sehen, was daraus wird.

gruss ekkehard

 

Hallo!

Ein möglicher Ablauf, wie man dein SQL-Debug mittels Add-In nutzen könnte:
Das Add-In wird als Access-Add-In installiert.
Wenn man das Add-In über das Add-In-Menü in Access öffnet, wird ein Formular geöffnet, mit dem man die Factory-Funktion in der aktuellen Anwendung installieren kann. (Codemodul in die aktuelle Anwendung einfügen.)
Danach muss der Entwickler nur noch die Factory-Funktion verwenden.

Das ist meiner Meinung nach anfängerfreundlich - zumindest für jene, die es schaffen das Add-In für die Aktivierung in der jeweiligen Anwendung über das Add-In-Menü/Add-In-Manager zu starten. *wink.gif*

Vorteil nebenbei: Wenn das Add-In einmal in einer neueren Version verfügbar ist, muss man in den Anwendungen nichts ändern, solange diese Factory-Prozedur nicht davon betroffen ist. Es reicht aus, die Add-In-Datei zu erneuern.

LG
Josef

 

Hallo Josef,
Dein erster Vorschlag, die DB als Verweis einzubinden funzt, und ist einfach.

Ein "richtiges" AddIn werde ich aber wohl ohne deine Hilfe nicht hinbekommen.
Nachdem, was ich nun gelesen habe, und mit deinem Codeschnipsel habe ich
zunächst versucht diese Tabelle "USysRegInfo" zu erstellen (siehe Anhang).
Wenn die so richtig wäre, und ich auch deinen Codeschnipsel verstanden habe,
- was macht "NewSqlDebugger()" ? Ist das die Function in der Tabelle ?
- "sDebugPrint" heisst dann nur noch "Print" ?

Was ich auch noch nicht verstanden habe, ist wie dies umzusetzen ist

In das AddIn muss also noch ein Formular (wahrscheinlich nur mit einer kurzen
Erklärung und einem Button. Wie wird das dann geöffnet? Das muss man ja für
jede DB nur einmal machen.
Und wie wird das Modul erstellt, - mit VBIDE ?

Noch eine Frage zum Codeschnipsel
Code:

Den Pfad kann ich doch nicht "fest verdrahten", wo bekomme ich den her?

Ich hoffe, dass ich mich nicht zu blöd anstelle (auch im Weiteren), aber das ist echtes
Neuland für mich.

gruss ekkehard

P.S. Gibt es vielleicht noch was Ausführlicheres zum Thema als das Whitepaper von
Thomas Möller?

 

Hallo!

Ich kann mich gar nicht erinnern, dass ich diesen Vorschlag machte. *wink.gif*


Der Pfad zum Add-In-Verzeichnis ist %APPDATA%/Microsoft/AddIns/
Kannst du entweder per API o. ä. ermitteln.

In meiner Standard-Install-VB-Script-Datei verwende ich
Code:

Ich würde die Funktion in einer Klasse kapseln, damit du vom Add-In nur eine Referenz an die laufende Anwendung übergeben musst und in der Anwendung dann bei Bedarf verschiedene Methoden auslösen kannst.
Vorteil der Referenz-Übergabe: sie muss nur dann angefordert werden, wenn noch keine verfügbar ist.

Tipp:
versuche zuerst nur die Variante mit dem Aufruf aus der Anwendung.
Das Konfigurationsformular und die Standard-Add-In-Funktionalität kannst du später erstellen.

mfg
Josef

 

Hallo Josef,
Was hab' ich mir da angetan *wink.gif*
Da ich den Ablauf immer noch nicht komplett verstanden habe, komme ich,
bitte nicht falsch verstehen, mit deinen Bröckchen nicht voran.
Ich wiederhole mich, - das ist für mich Neuland. Das muss ich mir Schritt für
Schritt erarbeiten.
Als Anleitung habe ich bisher nur das besagte Whitepaper von Thomas Möller
(ich hänge es mal dran).
(Da kommt auch dein erster Vorschlag her *wink.gif* )

Ich hänge immer noch an dieser nötigen Systemtabelle "USysRegInfo" fest,
da ich (noch) nicht verstehe, was da korrekt eingetragen werden muss.
Was ich bis jetzt probiert habe:
- eine Function "NewSqlDebugger" angelegt (MsgBox "BlaBla")
- die DB (DebugPrint_v2.4.mdb) konvertiert ( -> .mde -> .mda)
- versucht diese in einer anderen .mdb als AddIn zu installieren
Ergebnis:
- die AddIn-DB wird in das AddIn-Verzeichnis kopiert
- im AddIn-Manager wird es als "DebugPrint.mdb" angezeigt (?)
- dann die Fehlermeldung ich hätte nicht die erforderlichen Sicherheitsberech-
tigungen und möchte mich an den Admin wenden.
Da kann ich mich aber wenden wohin ich will, da bin nur ich *frown.gif*
Frage:
Liegt das an falschen Einträgen in der Tabelle?
Oder wo muss ich als Admin noch Rechte eintragen?

gruss ekkehard

P.S. Deine weiteren Anmerkungen aus dem letzten Post werde ich aufgreifen
wenn ich glaube soweit zu sein. Wobei den Code habe ich schon mal getestet,
und funzt bis auf einen Schreib- oder C&P-fehler.
Code:

da fehlt wohl ein Backslash am Anfang, und einer vor "AddIns"

 

Hallo!

Stimmt, bei Add-Ins muss man aufpassen. Wenn man die einmal erstellen kann und entdeckt wie praktisch die sein können, sieht man überall Add-In-Potential - hoch ansteckend! *Smilie


Bezüglich Reg-Tabelle: kopiere dir einfach die Tabelle aus meinem FilterForm-Assistent.
Dann musst du nur noch den Inhalt bezüglich Add-In-Namen anpassen.


Aber wie bereits erwähnt: für die Debug.Print-Funktionalität ist das nicht notwendig. Das brauchst du nur, wenn du das Add-In vom Add-In-Menü/Manager starten willst.

Ich bau heute in deine Beispiel-Datei den Aufruf ein, wie ich ihn mir vorstelle. ;-)

LG
Josef

 

Ein Beispiel zum Ausprobieren ist im Anhang.

Vorgehensweise:
1. install.vbs ausführen (ohne mde-Erstellung kopieren lassen) .. damit landet die mda-Datei im Add-In-Verzeichnis
2. SqlDebugPrintTest.mdb öffnen und die Prozedur im Modul _TEST ausführen.


mfg
Josef

 

Hallo Josef,
Erstmal vielen Dank für dein Beispiel. Schaue ich mir im Anschluss gleich an.

Alles klar, danke, da hat sich jetzt schon mal ein Knoten gelöst. Verstehe jetzt die
Einträge in der Tabelle. Dann kann ich die ja weglassen.

Jetzt mach' ich mich ans Beispiel.

gruss ekkehard

 

Hallo Josef,
Wahnsinn, das hätte ich ja in Wochen nicht hinbekommen.
Das WE ist zwar accessmässig ins Wasser gefallen, aber es eilt ja nicht.

Die Nebel lichten sich, so langsam verstehe ich die Zusammenhänge bezügl.
AddIns.
Am Anfang war ich etwas verwirrt wegen der zwei, gleichnamigen Module
"mdlDebugPrint". Vielleicht sollte man das, dass in die Anwendung kommt
"mdlDebugPrintErsatz" nennen, oder so das andere "mdlDebugPrintRef", -
wahrscheinlich besser.

Das was wir jetzt haben entspricht dann diesem

- richtig ?

Und der nächste Schritt wäre dieser ?

Also Erstellen der "USysRegInfo", der Startfunktion (öffnet Formular?), Code
zum Schreiben/Kopieren des Moduls.
Sag' erstmal nur Ja oder Nein, denn für ein Ja habe ich mir (dein Vorschlag)
schon Mal deinen FilterWizard angeschaut, denn da ist das ja schon realisiert,
wenn ich es soweit verstanden habe. Mich da durch zu wühlen, um es, zumindest
ansatzweise, zu verstehen und, vor allem, umzusetzen werde ich wohl ein paar
Tage brauchen.
Aber jetzt beiss ich mich da auch durch *wink.gif* - erstmal allerdings nur durch deinen Code.

gruss ekkehard