Seite 1 von 2

Datenbank (der Dauerbrenner :-))

Verfasst: 08.11.2005 12:50
von kalau
Hallo an alle,

nachdem ich mich jetzt auch nach längerer Pause wieder mit PureBasic beschäftigen darf,
möchte ich gleich ein paar Fragen zum Thema "Access-Datenbanken" loswerden,
da ich mit den in diesem und im englischen Forum gefundenen Sachen nicht so recht weiterkomme.

Ich möchte mit PureBasic eine Mitgliederverwaltung schreiben, da die bisherige "Software"
unter Access 2.0 (!) erstellt wurde, und das ganze so nicht mehr zeitgemäß ist.

Am besten ich lege einfach mal los:

1. Frage:
Von VB6 war ich gewohnt, daß man recht unkompliziert Daten aus Access-Abfragen weiterverarbeiten konnte,
sprich, man hat in Access bereits Abfragen definiert (beispielsweise "zeige nur aktive Mitglieder")
und konnte diese Ergebnisse direkt in VB weiterverarbeiten oder einfach im FlexGrid anzeigen.
Da dies ja bedeutend schneller ist als aus der Software heraus die identische SQL-Abfrage an die Datenbank
zu schicken wollte ich nachhaken, ob und wie man sowas in PB lösen kann.

2. Frage:
Die Datenbank enthält aktuell knapp 18.000 Datensätze mit jeweils 55 Feldern, ist also sehr umfangreich.
Wozu würdet ihr mir raten um die Daten in annehmbarer Geschwindigkeit auszulesen/ändern/speichern zu können?
(Bedingung ist leider, daß die Datenbank als MDB bestehen bleibt!)
Sollte ich die Daten in ein Array einlesen, oder sinnvollerweise lieber Structures verwenden?

Ich dachte mir das so, daß ich zum Beispiel alle Datensätze auslese, und im ersten Bild z.B. nur eine
Listenansicht (mit ListIcon) mit wichtigen Daten (Mitgliedsnummer, Name, Vorname) sehe,
und dann z.B. auf eine einzelne Zeile klicken kann damit sich ein neues Fenster öffnet,
in dem dann alle Mitgliedsdaten angezeigt werden (Name, Vorname, Adresse, Geburtsdatum etc.)

Hat jemand evtl. schonmal etwas ähnliches programmiert und kann mir hierbei weiterhelfen?
Oder hat jemand gar sowas schonmal programmiert und könnte mir (selbstverständlich gegen Entgelt)
Sourcecodes zukommen lassen?

Bin für jeden Hinweis dankbar, wo ich hierzu irgendwelche Codeschnipsel finden kann
um daraus zu lernen. Wie gesagt, eine Umstellung auf SQLite etc. ist derzeit leider noch nicht möglich.

Danke im voraus für Eure zahlreichen Zuschriften, gerne auch per PM. :D
und sorry, daß ich gleich im ersten Post so viel geschrieben habe... :oops:

Viele Grüße
Kalau

Re: Datenbank (der Dauerbrenner :-))

Verfasst: 08.11.2005 13:34
von Kiffi
Hallo Kalau,

kurze Frage, bevor ich detaillierter auf Deinen Beitrag eingehe: wieso bleibst Du nicht bei VB6?

Grüße ... Kiffi

Re: Datenbank (der Dauerbrenner :-))

Verfasst: 08.11.2005 13:56
von kalau
Kiffi hat geschrieben:Hallo Kalau,

kurze Frage, bevor ich detaillierter auf Deinen Beitrag eingehe: wieso bleibst Du nicht bei VB6?

Grüße ... Kiffi
Nuja, mit dem Nachfolger .NET kann ich mich nicht richtig anfreunden, und ich selbst besitze kein VB6
mehr, das mit den ganzen "Annehmlichkeiten" wie VSFlexGrid, VsView und sonstigen
OCX-Controls ausgestattet ist. Die hat mein alter Arbeitgeber behalten.

Nein, das ursprüngliche war bei diesem Projekt ja eine reine Acccess-Lösung, und ich wollte einfach eine schlanke Software erzeugen,
die man einfach ohne großartig einige MB installieren zu müssen auf einem beliebigen Rechner
aufspielen und problemlos wieder löschen kann.
Ich brauch Dir nicht zu sagen wie groß dieses Projekt ist, wenn man die ganzen o.g. OCX-Controls eingebunden hat... :(

[Außerdem geht es darum, daß ein Bekannter (ein leidenschaftlicher Verfechter von Java und C#)
das PureBasic als reinen"Kinderkram" abgetan hat, mit dem nur Script-Kiddies
ein paar Ballerspiele programmieren können, aber man damit keine vernünftige Software generieren kann.
Und gerade dem würde ich gerne das Gegenteil beweisen... :)]

Daher scheidet VB6 für dieses Projekt für mich erstmal aus,
wenn es irgendwie mit Pure zu lösen geht.

Gruß
Kalau

Re: Datenbank (der Dauerbrenner :-))

Verfasst: 08.11.2005 14:11
von Kiffi
> Daher scheidet VB6 für dieses Projekt für mich erstmal aus,

OK, das ist nachvollziehbar. ;-)

Gut, bevor es losgeht:

* Die Datenbank, um die es geht, ist schon vorhanden oder möchtest Du sie
aus PB heraus erstellen?

* Die Datenbankfunktionalitäten von PB kennst Du oder möchtest Du, dass
wir Dir einen kleinen Beispielcode aus der PB-Hilfe posten?

Grüße ... Kiffi

Verfasst: 08.11.2005 14:23
von bobobo
Ist doch ganz einfach..
Bei vorliegender Access-DB

Die Abfragen müssen in der Access-db als Abfragen vorliegen.


zb. eine KundenDB (erstellt mit dem Access-Assistenten) und dazu
eine Abfrage Alle_Ort_Da mit Inhalt
(select from Kunden where Ort like 'da')
erstellen.
im ODBC anmelden mit Name Kunden.

Die Abfrage lässt sich per SQL-Request abfragen und mit ff Code flott darstellen.

Code: Alles auswählen

Enumeration
  #Window_0
  #Button_Exit
  #ListIcon_0
EndEnumeration

Procedure getfromdb(DSN$,USER$,PW$,Request$)
  HideGadget(#ListIcon_0,1)
  If OpenDatabase(0,DSN$,USER$,PW$)
    If DatabaseQuery(Request$)
      FRowName$=DatabaseColumnName(0)
      If DatabaseQuery(Request$)
        nbcolumns = DatabaseColumns()
        ListIconGadget(#ListIcon_0, 0,0, WindowWidth(), WindowHeight()-20, FRowName$, 100,#PB_ListIcon_GridLines  | #PB_ListIcon_FullRowSelect  | #PB_ListIcon_HeaderDragDrop  | #PB_ListIcon_MultiSelect)
        For I = 1 To nbcolumns-1
          AddGadgetColumn(#ListIcon_0, I, Trim(LCase(DatabaseColumnName(I))), 2)
        Next I
        While NextDatabaseRow()
          getInhalt$=""
          For ii=0 To nbcolumns-1
            getInhalt$ + GetDatabaseString(ii)+Chr(10)
          Next ii
          AddGadgetItem(#ListIcon_0,-1,getInhalt$)
        Wend
        For I =1 To nbcolumns-1
          SendMessage_(GadgetID(#ListIcon_0),#LVM_SETCOLUMNWIDTH,I,#LVSCW_AUTOSIZE_USEHEADER)
        Next I
        CloseDatabase(0)
      EndIf
    Else
      MessageRequester("","Database "+DSN$+" doesn't obey You",0)
      End
    EndIf
  EndIf
  HideGadget(#ListIcon_0,0)
EndProcedure

InitDatabase()

;hier die ODBCDaten eintragen

DSN$="Kunden"        ; <--------- SQL-Datenbankdaten
USER$=""             ; <--------- SQL-Datenbankdaten
PW$=""               ; <--------- SQL-Datenbankdaten


wx=GetSystemMetrics_(#SM_CXSCREEN)
wy=GetSystemMetrics_(#SM_CYSCREEN)
If OpenWindow(#Window_0, wx-410 ,0, 400,400,  #PB_Window_MaximizeGadget|#PB_Window_MinimizeGadget|#PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_TitleBar , "kleiner Datenbankangucker")
  If CreateGadgetList(WindowID())
    ListIconGadget(#ListIcon_0, 0,0, WindowWidth(), WindowHeight()-20, FRowName$, 100,#PB_ListIcon_GridLines  | #PB_ListIcon_FullRowSelect  | #PB_ListIcon_HeaderDragDrop  | #PB_ListIcon_MultiSelect)
    ButtonGadget(#Button_Exit,WindowWidth()/3*2,WindowHeight()-20,WindowWidth()/3,20,"Exit")
  EndIf
EndIf

;Request$="select * from [Alle Ort Da]" ; <--------- SQL-Abfrage mit Leerzeichen im AbfrageNamen
Request$="select * from Alle_Ort_Da " ; <--------- SQL-Abfrage

getfromdb(DSN$,USER$,PW$,Request$)
Repeat
  Event = WaitWindowEvent()
  If Event =#PB_Event_SizeWindow
    ResizeGadget(#ListIcon_0,0,0, WindowWidth(), WindowHeight()-20)
    ResizeGadget(#Button_Exit,WindowWidth()/3*2,WindowHeight()-20,WindowWidth()/3,20)
  EndIf
  If Event = #PB_EventGadget
    GadgetID = EventGadgetID()
    If GadgetID = #ListIcon_0
      Debug "GadgetID: #ListIcon_0"
    EndIf
    If GadgetID=#Button_Exit
      End
    EndIf
  EndIf
Until Event = #PB_EventCloseWindow
End

Re: Datenbank (der Dauerbrenner :-))

Verfasst: 08.11.2005 14:46
von kalau
Kiffi hat geschrieben:> Daher scheidet VB6 für dieses Projekt für mich erstmal aus,

OK, das ist nachvollziehbar. ;-)
Schön daß Du mich verstehst... :mrgreen:
* Die Datenbank, um die es geht, ist schon vorhanden oder möchtest Du sie
aus PB heraus erstellen?
Die Datenbank ist vorhanden, alle benötigten Abfragen habe ich auch schon in der Datenbank stehen.

* Die Datenbankfunktionalitäten von PB kennst Du oder möchtest Du, dass
wir Dir einen kleinen Beispielcode aus der PB-Hilfe posten?
Ich habe mein Projekt mit MDB_Connect, DatabaseQuery und NextDatabaseRow() angefangen. "Bessere" Lösungen sind natürlich immer gerne gesehen... :)
Die Frage ist halt einfach wie ich mit den Daten sinnvoll umgehe, sprich in welcher Form ich mir diese doch recht große Datenmenge in den Speicher ziehen sollte (Array, Structure, ???) um damit arbeiten zu können (Suche, Update, Neuanlage, Speichern etc.).

Bei meinen ersten Versuchen die "Rohdaten" auszulesen und in die einzelnen Spalten eines ListIcon zu schreiben dauerte furchtbar lange. Hierbei wurde auch die Bildschirmanzege nicht mehr aktualisiert bis das Teil gefüllt war. Und das dann mit delay noch auszubremsen (wegen der Aktualisierung) ist ja auch nicht sinnvoll. :(

Gruß
Kalau

Verfasst: 08.11.2005 15:14
von kalau
bobobo hat geschrieben:Ist doch ganz einfach..
Bei vorliegender Access-DB
Hervorragend! Danke, das ist schonmal ein Riesenschritt nach vorne! :allright:

Ich habe es natürlich gleich mal getestet.
Wenn ich alle Datensätze der "Rohdaten" einlese dauert es ca. 15 Sekunden bis alle
komplett ausgegeben werden. (bei 17808 Datensätzen à 55 Feldern eine brauchbare Zeit).

Hast Du auch noch eine Idee wie ich die Daten sinnvollerweise einlese
um sie zu bearbeiten?
Sprich, wenn ich eine einzelne Zeile im ListIcon anklicke den ganzen
zugehörigen Datensatz erhalten kann?
Ich habe keine Idee wie ich eine einzelne Zeile so zuordnen kann,
daß ich den betreffenden Datensatz einem separaten Fenster übergeben
kann. Ein eindeutiges (indiziertes) Merkmal (Mitgliedsnummer) liegt vor.

Wäre es dafür einfacher, wenn man auch diese Abfrage direkt in Access
schreibt, von PB als Parameter an Access übergibt (wie?)
um dann das Access-Ergebnis als einzelne Strings (Mitgliedsnummer,
Name, Vorname, Ort, ...) in die jeweiligen #String-Textfelder schreibt?

Dann bräuchte ich ja ggfs. nicht unnötig Speicher mit einem Array oder
Structure zu verschwenden wenn ich den betreffenden Datensatz
eindeutig identifizieren kann um ihn auszulesen und nach Änderung
zurückzuschreiben, oder?

Ah, bin schon ganz wild drauf mit diesem Code weiterzubasteln... :allright:

Herzlichen Dank nochmal für die ausführliche Antwort!!!

Kalau

Verfasst: 08.11.2005 15:35
von kalau
Habe gerade nochmal drüber nachgedacht. Für Suchfunktionen wäre es doch sicherlich schneller,
wenn man den gesamten Datenbestend im Speicher vorhält, als wenn man da z.B. den
Parameter "Müller" an Access übergibt und als Ergebnis alle "Müller" zurückgeliefert bekommt?

Frage: Wie würdet ihr das machen, eher über die Datenbank oder doch besser im Speicher vorhalten?

Gruß
Kalau

Verfasst: 08.11.2005 15:40
von Kiffi
> Frage: Wie würdet ihr das machen, eher über die Datenbank oder doch
> besser im Speicher vorhalten?

lieber in der Datenbank. Damit erhälst Du Dir auch die Möglichkeit, dass
irgendwann mehrere Anwender mit der DB gleichzeitig arbeiten können.

Grüße ... Kiffi

Verfasst: 08.11.2005 15:55
von stbi
In der Datenbank. Die kann Dir außer der reinen Datenhaltung an sich auch viele Aufgaben abnehmen bzw. beschleunigen, z.B. Suchen, Abfragen. Allerdings wirst Du Dich zwangsläufig mit SQL beschäftigen müssen.