Alinas_SQLite_BuchVw

  • Alinas_SQLite_BuchVw ist ein AutoIt-Listview, neben Editfeld und Gui eine weitere Möglichkeit seine Datenbankinhalte zu präsentieren. Also eine Sichtweise, die uns aus Officeprogrammen geläufig ist, die nun mit der Funktionalität von relationalen Datenbanken einhergeht.


    In diesem Anwendungsbeispiel handelt es sich um eine Datenbank mit einer einzelnen Tabelle, in der eine Büchersammlung verwaltet werden soll. Beim Start der Sammlung soll die Tabelle der Datenbank einige Eckdaten aufnehmen, z.B. ID, Titel, Autor, Erscheinungsdatum und die ISBN.


    Das Datum –
    Mit dem SQL-Befehl “SELECT date(‘now’);” wird nicht nur das aktuelle Datum angezeigt, sondern auch das SQLite interne Datumsformat (YYYY-MM-DD), das in diesem Fall verwendet wird.


    Die Bedienung
    ist denkbar einfach und schnell erklärt. Nach dem Start des Programms wird die DB mit “DB laden” geladen.
    Die Suche funktioniert so, den Suchbegriff eingeben und im Combofeld hier “Titel” voreingestellt eine Auswahl treffen. Nach dem Klick auf “Suche starten” erscheint die Ausgabe im ListView. Zur DB zurück mit “DB laden”.


    Um einen einzelnen Datensatz zu bearbeiten, wechselt man in den Bearbeitungsmodus. Bei einem Rechtsklick auf den jeweiligen Datensatz wird dieser in die Eingabefelder eingefügt und man kann prüfen, ob man eventuell in der Zeile verrutscht ist. Hier können die Datensätze auch eingegeben, geändert oder gelöscht werden. Bevor es losgeht aber erst einmal ein Backup mit “DB BackUp”, nun erhält man eine Txt-Datei, die auch von einem Officeprogramm eingelesen (Daten-Import) werden kann.


    Edit siehe Post #3: Download "sqlite3xx_dll.au3" :
    http://ritzelrocker04.bplaced.…torials/sqlite-starterlv/


    PS: Schöne Feiertage!


  • DLL anbei

    Dateien

    ...... Lieben Gruß, ........
    ...........
    Alina ............

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Ich habe die Deutsche Hilfe auf meinem PC und
    OrganizeIncludes ist beim Scripten mein bester
    Freund. Okay?

    Einmal editiert, zuletzt von Alina ()

  • Schaut gut aus ;)

    ...... Lieben Gruß, ........
    ...........
    Alina ............

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Ich habe die Deutsche Hilfe auf meinem PC und
    OrganizeIncludes ist beim Scripten mein bester
    Freund. Okay?

  • Vielen Dank an RR04, für das schöne Code-Beispiel! :thumbup:


    Gestern habe mich endlich dazu durchgerungen, ein laaange vor mir her geschobenes Projekt zu realisieren. Die Wahl fiel dabei auf AutoIt & SQLite. Mit beidem bin ich zwar noch Anfänger, habe aber doch einige Erfahrung mit anderen Basic-Dialekten.


    Obiges Listing erschlägt schon einen ziemlich dicken Teil meines angestrebten Programms (für dass ich demnächst einen neuen Thread starte).
    Nur: Leider läuft die Buchverwaltung bei mir nicht ganz korrekt.


    Änderungen an den Einträgen werden zwar in der Listview angezeigt und beim Betätigen des "Speichern"-Buttons auch tatsächlich in die Datei "buchverwaltung.rr04" geschrieben (die sich ordnungsgemäß neben der Scriptdatei befindet), doch beim nächsten Programmstart (der stets mit leer dargestellter Listview erfolgt) und erneutem Laden der Datenbank, sind die letzten Änderungen wieder futsch und es werden die direkt im Quellcode hinterlegten Rohdaten in der ListView dargestellt.
    Leider gelang es mir noch nicht, das Problem selbst zu beheben. :Face:


    Etwas sonderbar erscheint mir die Zeile 127 ... öh, was soll da passieren (und warum)?


    Für mein geplantes Projekt würde ich natürlich allerhand Anpassungen & Erweiterungen vornehmen - doch dazu bräuchte ich zunächst ein lauffähiges Grundgerüst, als Einstieg.


    Die Feldbezeichner (heißen die so?) kommen mehrfach (redundant) im Quelltext vor.
    Weil ich die sowieso alle ändern müsste und weil Mehrsprachigkeit nett wäre, würde es sich IMHO anbieten, diese aus einer ini-Datei zu laden.
    RR04 hat auch diesbezüglich ja bereits ein Bespiel auf seiner Homepage, das förmlich danach schreit, in die (derzeitige) Buchverwaltung integriert zu werden.


    Mein eigenes Projekt wird übrigens eine Verwaltung für Reparaturaufträge, mit integrierter Bauteildatenbank/Lagerverwaltung. Doch mehr dazu demnächst in einem eigenen Thread.


    Es wäre schick, wenn zunächst mal die Buchverwaltung bei mir laufen würde.
    Kann es übrigens sein, dass eine Funktion zum Hinzufügen neuer Datensätze noch fehlt?

  • Danke, autoBert!
    Komisch: Gestern hatte ich genau das schon ausprobiert, aber da trat der sonderbare Effekt auf, dass die Standard-Einträge plötzlich mehrfach in der Datenbank vorhanden waren, nebst einigen neuen.
    Als mir das auffiel, war die Datenbank bereits auf 67 Datensätze angewachsen.
    All meine Versuche, die Ursache dafür zu finden, scheiterten.
    Keine Ahnung, was gestern schief lief, aber heute noch mal frisch probiert, geht's. Danke!


    Eine Frage an RR04:
    Hast Du für die Gestaltung des GUI einen Designer verwendet?
    Oder hast Du einfach so lange im Script herumparametriert, bis es so schön schnuckelig aussah?


    Ich hatte vor 10 Jahren mal eine umfangreiche Applikation in VB.Net programmiert. Die nahm mit der Zeit so einen derben Umfang an, dass ich am Ende auf den grafischen Designer von VB.Net hustete.
    Statt dessen las das Programm die Positionsdaten und sonstigen Parameter der Bedienelemente bei Programmstart aus einer ini-Datei ein.
    So konnte jeder User (mit viiieeel Geduld) eigene Anpassungen am Design vornehmen.
    Ganz glücklich war ich mit diesem Verfahren aber auch nicht, weil es einfach gar zu schwierig war, eine komplexe und reichlich mit Elementen vollgekleisterte Oberfläche per Editor, oder Excel umzugestalten.


    Da suche ich also noch nach einem brauchbaren Weg, der es dem unbedarften User ermöglicht, einigermaßen komfortabel eigene Anpassungen am Design vorzunehmen.

  • Nein. Er hat keinen Designer verwendet. Sieht man daran, dass die Controls in nem Array erstellt werden. Sowas ist immer sehr sinnvoll, wenn man sich wiederholende Strukturen hat.
    Allgemein sind Designer in AutoIt nicht allzusehr zu empfehlen, wenn man nicht mal eben schnell was zusammenbasteln will, oder die Controls noch nicht kennt.
    Das liegt aber daran, dass es keine Layouts gibt, die zum Beispiel beim resizen,... viel Vereinfachen.
    Das Prinzip könnte man aber mal nachbauen... Wäre mal ne Idee für ne UDF. So immer weiter Elemente verschachteln,... werd ich mir mal überlegen :)

  • Ja, das war auch der Grund, warum ich damals auf den Designer verzichtete.
    Es kommt bei einzelnen Anwendern vor, dass sie oft Daten von Listen abtippen müssen. Dazu machen die dann beispielsweise ein schmales Editorfenster auf und ziehen das Fenster meines Programmes ebenfalls schmaler, um es neben dem Editor zu platzieren.


    Mit fixen Positionen für die Bedienelemente, die sich an einem starren Fenster mit unveränderbaren Abmessungen orientieren, würde das nicht gehen.
    Doch wenn man frei schwimmende Elemente verwendet, die sich den Abmessungen eines in der Größe veränderbaren Fensters dynamisch anpassen, dann kann es vorkommen, dass es nun so richtig müllig aussieht, weil die Bedienelemente sich sonstwie anordnen.
    Arbeitet ein User praktisch immer mit einer bestimmten, individuell eingestellten Fenstergröße, so kommt folglich rasch der Wunsch auf, das Layout entsprechend aufzuräumen.


    Sehr fortgeschrittene Programme haben dafür dann einen eingebauten Modus, der die Umgestaltung per Maus ermöglicht, wie bei einem eigenständigen GUI-Designer.
    Sooo weit wollte ich nicht unbedingt ausholen. Aber ein gangbarer Mittelweg, zwischen Programmieraufwand und Flexibilität, wäre schon schick.

  • Wie schon ja "angedroht", baue ich derzeit ein eigenes Programm, das auf der prima Code-Vorlage von RR04 aufbaut (vielen Dank an RR04!).


    Bevor ich dazu einen eigenen Thread starte, wollte ich zunächst noch einmal meinen derzeitigen Stand der Umbauarbeiten hier im Thread zu Alinas Bücherverwaltung mit Euch teilen.
    Denn NOCH hat das Programm Ähnlichkeit mit RR04s Fundament und ich dachte mir, dass mein Code-Stil (den ich für übersichtlich halte) vielleicht Anregungen liefert.


    Großartig neue Features sind noch nicht hinzu gekommen - mal abgesehen von der Menüleiste.
    Meine Arbeit bestand hauptsächlich darin, den Code (nach meinem Ermessen) ein gutes Stück übersichtlicher und leichter pflegbar zu gestalten (wodurch er schon reichlich angewachsen ist).
    - Ein Prozess, der zwar noch nicht ganz abgeschlossen ist, aber meine nächsten Umbauten werden den Code so stark verändern, dass er mit Alinas Bücherverwaltung nicht mehr viel zu tun hat. Und ich wollte Alina noch die Chance geben, was zu verwerten, falls ihr etwas brauchbar erscheint.
    Denn in der jetzigen Form scheint es mir eine schon ziemlich gute Basis für ähnlich gelagerte Aufgaben zu sein.


    Soweit ich neue Variablen eingefügt habe, hielt ich mich an die hier im Forum empfohlenen Konventionen.


    Die Erzeugung der Musterdatensätze erfolgt nun wirklich nur dann, wenn die Datenbankdatei noch nicht existiert. Damit gab es Anfangs ja ein Problem ...
    Allerdings werden bereits jetzt Datensätze für eine Reparaturverwaltung erzeugt, statt für eine Bücherverwaltung. Die Textboxen sind aber daran noch nicht angepasst und noch an Ort und Stelle. Auch die Anzahl der Felder habe ich derzeit noch nicht verändert (jedoch deren Breite und Textausrichtung in der ListView); Alina wird also den jetzigen Stand ganz leicht wieder an ihre Bedürfnisse anpassen können.


    Hoffentlich ist meine Danksagung, die per Menü aufrufbar ist, ausreichend, um die Vorarbeit von RR04 und BugFix angemessen zu würdigen?
    - Sonst meckert, dann intensiviere ich meine Lobpreisungen!


    Vorschau auf die nahe Zukunft (dann in einem eigenen Thread):
    Mein nächster Umbau wird sein, dass die Oberflächengestaltung aus einer Datei geladen wird, damit man nicht so viel im Quelltext herumwühlen muss, um das GUI umzugestalten.
    Außerdem implementiere ich weitere Ansichten, z. B. eine Vollbilddarstellung für die ListView-Tabelle.
    Später kommt noch eine relationale Verknüpfung mit einer Adressdatenbank und einer Geräte-Datenbank hinzu.
    Weiterhin wird für jeden Reparaturauftrag ein Ordner erzeugt werden, der Bilder, Datenblätter und sonstige Dateien beinhalten kann, die dann per Verknüpfung aus dem Programm flott aufrufbar sind.
    Langfristig kommen noch diverse Druckfunktionen für Formulare (Reparaturannahme-Beleg) und gaaanz später die Möglichkeit, Rechnungen zu drucken (hier wird es aber langsam komplex, ich weiß!).


    Ich habe also Groooßes vor; wir werden noch miteinander zu tun haben! :-)


  • Hi genau das was ich gesucht habe, besteht die Möglichkeit das man zum ersten Feld hinter der ID noch eine Inputbox plaziert und da Zahlen und Buchstaben eingeben kann also zum Beispiel Kundennummer bekomme es nicht hin kann mir da jemand helfen ???

  • Ich hab das eben umgesetzt :)

    Code-Jack hat es schon recht gut umgesetzt, dass es Flexibel ist. Kann man nur an wenigen Stellen noch optimieren. So musste doch noch an mehreren Stellen was geändert werden ;)


    MfG Kanashius

  • Boah, ist der Kanashius schnell!
    Man kann hier wirklich nur den Hut ziehen, vor den hoch kompetenten und überaus hilfsbereiten Usern, echt!
    Großartige Leute hier, beide Daumen hoch!


    stefanwue :
    Obige Version ist noch eine recht frühe Baustelle.
    Ich habe das Programm seither ein gutes Stück weiter entwickelt. wichtig war es mir, dass man die Maske jederzeit vom Programm aus, per Maus, umgestalten kann.
    Dass die Daten für die Maskengestaltung also nicht fest im Quelltext codiert sind, sondern aus einer Ini-Datei eingelesen werden.


    Ist nie ganz fertig geworden und die aktuelle Version ist noch immer nicht wirklich einsetzbar (hat auch noch Fehler), aber ich hänge dennoch mal meinen letzten Stand an, weil sich da doch sehr viel getan hat.




    Wie gesagt: Noch immer volle Baustelle, aber schon sehr viel weiter entwickelt, als die im weiter oben stehenden Posting enthaltene Version.

  • #RequireAdmin

    #AutoIt3Wrapper_UseX64=n

    我寄望于去做修女,夜夜祷告.静坐.请求所有人的宽恕.并远离尘世的痛苦.与晨露为伴.永不思红尘之事.我梦想有一天,暖暖的太阳透过窗户照在我安详的脸上,使我觉得自己仍然纯洁.我将会快乐

  • Nach zwei Jahren Abstinenz kramte ich den Quellcode endlich mal wieder hervor.

    Damals wuchs mir die Sache über den Kopf, dabei bräuchte ich das Programm eigentlich täglich ...

    - Jetzt brauche ich es aber wirklich definitiv und nicht mehr aufschiebbar!



    Aktuell scheitert es an einer simplen Sache:

    Ich möchte, wenn ein Datensatz editiert werden soll, die ganzen Inputboxen nicht mehr aus der ListView befüllen (wie einst im Ursprungs-Quelltext), sondern direkt aus der eigentlichen Quelle, also der SQLite-Datenbank.

    Grund: Die ListView soll später nur noch die relevanten Datenfelder darstellen. Der zu editierende Datensatz ist also umfangreicher, als das, was man in der ListView sieht.


    Es würde mir schon riesig helfen, wenn man mir auf die Sprünge helfen könnte, wie ich aus der Datenbanktabelle ein einzelnes Feld auslesen kann, anhand des Wertes in der Spalte "ID". Dann würde ich den Rest selbst schaffen.

    Seit gestern grase ich deswegen das Forum durch, probiere Beispiele aus, folge diversen Links auf SQL-Erklärbär-Seiten ... doch alle Beispiele bringen nicht das, was ich will, sind viel zu komplex und vergrößern meine Verwirrung nur.


    Anbei der gesamte Quelltext.

    Die Routine, die es bringen soll, ist in Zeile 659: "Func _Datensatz2Inputboxes"


    Wie man sieht, ist die Routine inzwischen vollständig zu Klump gemüllt, von den vielen dutzend erfolglosen Tests.


    Frage also: Wie kriege ich einen einzelnen Feldinhalt der Datenbank (definiert anhand der ID des in der ListView selektierten Datensatzes) ausgelesen, um ihn einer InputBox zuzuweisen?

  • Hallo Code-Jack

    Ich habe mir das Skript noch nicht angesehen. Allerdings scheint mir das auch keine Frage zu diesem Skript, sondern zu SQL bzw. SQLite zu sein.

    Frage also: Wie kriege ich einen einzelnen Feldinhalt der Datenbank (definiert anhand der ID des in der ListView selektierten Datensatzes) ausgelesen, um ihn einer InputBox zuzuweisen?

    Lass uns behaupten, dass Feld würde ID heißen. Dann könnte der Befehl lauten: SELECT * FROM TABELLENNAME WHERE ID = Whatever


    Ich bin sicher, dein Problem ist gar nicht so groß- Schau dir einfach mal SQLite-Tutorials an.

  • Ich bin sicher, dein Problem ist gar nicht so groß- Schau dir einfach mal SQLite-Tutorials an.

    Waah, dessen bin ich mir auch sicher! Und ich habe ausgiebig Tutorials gewälzt, trotzdem klappte es partout nicht.

    Nach ungefähr 15 Stunden kauen an diesem kleinen Problem war ich dann doch so weit, mal im Forum zu fragen.


    Aaaber - Tadaaa! - ich habe es inzwischen selbst geschaft! :party:

    Der User TheLaBu hat im folgenden Thread ein Beispiel gebracht, das ich erfolgreich abwandeln konnte:

    SQL-Ergebnis als Variable speichern


    Der aktualisierte Quelltext hängt noch einmal an, falls einem Anderen mal nützlich sein könnte.

    In dieser Form ist das Programm nämlich schon recht nahe an der ersten Brauchbarkeit (obwohl noch dick Baustelle).


    Trotzdem Danke für Deine Meldung. Ich habe schon viel aus Deinen anderen Postings gelernt!

  • Etwas verlegen bin ich geneigt zu behaupten, die Codevorlage des geschätzten RR04 enthält einen Bug, der sich bloß nicht bemerkbar macht.

    Ich habe ja eine Menge von dieser Vorlage abgekupfert und immer mehr erweitert. Und niemals ist mir dieser Bug aufgefallen, weil er halt nie in Erscheinung trat.


    Doch nachdem ich nun in meinem Programm die SQLite-Tabelle nicht mehr mit INTEGER AUTOINCREMENT für die ID kreiere, sondern dort eine GUID als TEXT (statt Integer) verwende ...

    siehe hier: Datenbank dezentral erweitern [gelöst]

    ... trat der Bug plötzlich in Erscheinung. Sogar gleich in zwei Routinen.

    Nun ja, bei mir selbst beseitigte ich den.


    Interessiert kramte ich den alten Code von RR04 wieder hervorund tatsächlich ist er dort schon vorhanden.

    Hier die Stelle um die es geht:



    Meines bescheidenen Erachtens fehlen hier zwei Hochkommas.

    Die letzte Zeile müsste IMHO so aussehen:


    Code
    1. & GUICtrlRead($aCtrlInput[20]) & "' WHERE ID = '" & GUICtrlRead($aCtrlInput[0]) & "';")


    Wie gesagt: Der (von mir so betrachtete) Bug machte sich bisher nie bemerkbar. Vermutlich weil die als Integer erzeugte ID von SQLite als Zahl verdaut wurde und daher keine Einfassung in Hochkommas benötigte.

    Ich hingegen, verwende nun neuerdings keinen Integer mehr als ID, sondern einen String. Und dann klemmt es, ohne die Einfassung.


    Weil hier ja doch viele Codebeispiele mit SQLite im Forum zu finden sind (was vermuten lässt, dass die Macke verbreiteter ist) und weil mir die Vorlage von RR04 so gut gefiel, wollte ich mal dezent darauf hingewiesen haben.

    Da kann man sich in unübersichtlicher gestalteten Vorlagen, als dieser hier, ja sonst 'nen Wolf deduggen, als SQL-Anfänger.


    Konzeptionelles:

    Ich stricke mein Programm übrigens so, dass am Ende nur genau eine einzige Routine Daten aus der SQLite-Datenbank holt.

    Und nur genau eine einzige Routine schreibt Daten hinein.

    Alle sonstigen Routinen, die irgendwie Daten aus/in SQLite holen/schreiben wollen, tun das nicht mehr direkt, sondern über eine zwischengeschaltete Func, die den jeweiligen Befehl auf die Schreib- bzw. Leseroutine leitet.


    Darin sehe ich zwei Vorteile:

    Erstens erpart man sich massig Fehlerquellen. Dieser SQL-Kram ist ja echt so ein Ding für sich.

    Zweitens kann man blitzschnell völlig andere Datenquellen implementieren.

    Wenn also eines Tages statt SQLite eine ganz andere Datenstruktur gefordert wird, dann braucht man nur eine neue Schreib- und eine neue Leseroutine zu stricken und die Umleitung halt ... umleiten.

    Man muss dann also nicht umständlich an gefühlt 1000 Stellen im Programm Hand anlegen, wo irgendwas mit SQL passiert.



    Noch eine konzeptionelle Sache, nur als Anregung:

    Wenn ein Datensatz in der Maske editiert wird, dann schreibe ich die Daten im Anschluss zuerst in die SQLite-Datenbank. Anschließend lese ich sie von dort wieder aus und aktualisiere mit den daraus ausgelesenen Daten (die zunächstin ein Array wandern) die ListView, oder was auch immer.


    Darin sehe ich folgende Vorteile:

    Erstens fällt es sofort ins Auge, wenn bei den SQL-Aktionen etwas (ohne Fehlermeldung) schief gegangen sein sollte.

    Zweitens verringert sich die Anzahl an Routinen, die irgendwie eigenmächtig Daten lesen, schreiben und kreuz und quer untereinander hin & her konvertieren.


    Also statt aus den Editfeldern auszulesen und damit die ListView zu füllen und dann irgendwie in die Datenbank ... ist der Datenfluss bei mir irgendwie klarer strukturiert.

    Die Quelle für alles ist immer die Datenbank!

    Und die wird stets zuerst schreibend aktualisiert. Erst von da aus werden dann erst Edits, Listviews etc. befüllt/aktualisiert - stets direkt aus der Datenbank kommend.

    (Mit einem dazwischen geschalteten Array, sei der Vollständigkeit halber noch erwähnt).


    Nur eine einzige Routine schreibt in die Datenbank.

    Und nur eine einzige Routine holt Daten dort heraus.

    Alles sonstige läuft über ein dazwischen geschaltetes Array.

  • Hallo Code-Jack  

    Wie gesagt: Der (von mir so betrachtete) Bug machte sich bisher nie bemerkbar. Vermutlich weil die als Integer erzeugte ID von SQLite als Zahl verdaut wurde und daher keine Einfassung in Hochkommas benötigte.

    Ich hingegen, verwende nun neuerdings keinen Integer mehr als ID, sondern einen String. Und dann klemmt es, ohne die Einfassung.

    Daher ist es kein Bug, sondern war so wie es angelegt war völlig korrekt. Wenn man daran Änderungen vornimmt, muss man eben wissen, was man warum ändern muss. Du machst es nun natürlich besser. Bulletproof finde ich es aber auch noch nicht. Du solltest am besten allgemein die Funktion _SQLite_Escape benutzen (dann sparst du es dir auch eventuelle Steuerzeichen im Text escapen zu müssen).