Entwickler-Ecke

Datenbanken - Datamodul-Handling


hansa - So 01.12.02 21:20
Titel: Datamodul-Handling
Hi Leute,

dieses mal geht es mir darum, wie ich am besten mit einem DataModule umgehe. Hintergrund ist folgender : ich habe jetzt hier mal 14 Tables, die bereits mit Daten gefüllt sind. Keine Blob-Felder oder sowas, nur Zahlen und strings (GDB hat ca. 15 MB).

Also zumindest eine Grundlage. Um diese Daten zu erhalten, habe ich für jede Table ein Programm geschrieben, welches die alten Daten umwandelt und in die neue DB schreibt. Da ich das mit 14 Tables bereits mit jeweiils einem DataModul realisiert habe, stellt sich nun folgende Frage :

ich will diese Woche irgend so ein Mini-Rechnungsprogramm machen, wobei nach Eingabe der Rechn.Nr. die Rechnung gedruckt wird. Wie die aussieht ist mir vorläufig egal. 8) Wennn ich hierzu ein Datamodul verwende muß ich doch folgendermaßen vorgehen :

Database, Transaction, Datasets da rein tun. Brauche ich zu jeder Table eigentlich ein Datasource ? Naja da fängts halt schon an. Als Datasets brauche ich ja wohl mindestens Rechnungskopf, Kunden, Artikel, Rechnungspositionen. Jetzt hab ich noch ein Datamodul anlegen wollen. Aber dann müßte ich doch alles noch einmal machen, die ganzen SQLs, OI-Einstellungen usw. obwohl fast alles vorhanden ist. :cry: Wenn ich statt dem einfachen Rechnungsdruck eine Rechnung schreiben wollte, bräuchte ich alles aus dem Rechnungsdruck-Modul, zusätzlich aber noch z.B. den Lagerbestand. Wenn ich die Datamodules so weiter benutze, hab ich nachher 200 Stück. Das kann ja wohl nicht sein, oder doch :?: Das einzige, was mir dazu einfällt, ist an den DFM zu hantieren und alles von Hand reinzuschreiben.

Gruß
Hansa


hansa - Do 05.12.02 13:13

Hi,

weiß keiner was dazu zu sagen ? Komme nicht weiter

Gruß
Hansa


LCS - Do 05.12.02 14:00

Hi
den Thread muss ich glatt überlesen haben :? Allerdings ist die Problematik mit den Datenmodulen stark Projektabhängig. In der Regel verfahre ich so, dass ich ein Hauptdatenmodul erstelle.
Da drin ist die Datenbank, Transaktionen und vor allem Tabellen von denen absehbar ist, dass sie in jedem Programm verwendet werden (Kennziffern, Texte usw.).
Dieses Modul wird durch ein aufgabenspezifisches Modul je Programm ergänzt. Dort befinden sich dann nur Tabellen, Datasources usw. die für die Anwendung benötigt werden. Dieses Modul verwendet die Datenbankverbindung aus dem Hauptmodul. Bei klitzekleinen Anwendungen, die ausser dem Hauptmodul vielleicht noch ne extra Tabelle brauchen, wird nicht extra ein Modul erzeugt, sondern das setz ich dann direkt in das entsprechende Formular.
Mit der Aufteilung bin ich bis jetzt bei allen Projekten gut klargekommen. Die gesamte Datenbankanbindung steht an einer Stelle (Hauptmodul) die Aufgaben sind zusammengefasst und das Ganze ist trotzdem übersichtlich.

Gruss Lothar


Udontknow - Do 05.12.02 15:29

* SCHNIPP durch Selbstzensur*

Wer lesen kann, ist klar im Vorteil, ich bin manchmal im Nachteil... :oops:
:mrgreen:
Cu, :)
Udontknow


hansa - Fr 06.12.02 00:35

Hi,

@Admin : Letzter Beitrag kann unbesorgt gelöscht werden.. Zu früh abgeschickt. :mrgreen:

Lothar hat mal wieder was richtiges gesagt. Nur: Ich brauche ca. 10 Datamodule. Wie soll ich die sinnvoll verknüpfen ohne alles durcheinander zu bringen ? Soll ich die nur in die USES Liste eintragen ? Und was dann und wie weiter ?

Bin im Moment mit bestehenden Daten beschäftigt. Die stimmen einwandfrei. Nur wie gehts weiter ? Die Datenmodule von 14 Tables funktionieren. Dafür gibt es aber jeweils ein eigenes Programm, in dem die Datenmodule hinterlegt sind. Diese wollte ich verwenden und weiß nicht wie. Wenn ich in die Zukunft denke, könnte ich das ganze doch bestimmt universell einsetzen. :mahn:

Der Ansatz von Lothar ist auch sinnvoll, wollte z.B. in das Rechnungs-DataModul folgendes reinpacken :

- Rechnungskopf
- Kunde
- Rechnungspos.
- Artikel zur Rechnung

für Sonderfälle :

- Rabattpos.

Ersteres wäre also das HauptModul. Sonderfälle könnte ich ohne DataModule behndeln.

Gruß
Hansa


hansa - So 15.12.02 21:45

Hi,

das Thema ist noch nicht abgehakt :!: Wen es interessiert sollte sich das hier mal ansehen, ist aber auf englisch (bin auch gerade am lesen) :

http://www.dbginc.com/tech_pprs/ibxcds.html

Gruß
Hansa


hansa - Di 17.12.02 15:34

Hi,

hat sich vielleicht das obige jemand angesehen und die Beispiele ausprobiert ?

Das Programm heißt IBXdemo. In der Unit MainF erhalte ich bei folgender Prozedur :

Quelltext
1:
2:
3:
4:
procedure TMainForm.FormCreate(Sender: TObject);
begin
  Keys := VarArrayCreate([0, 2], varVariant);
end;


den Fehler "undeclared Identifier 'VarArrayCreate'". Am Quelltext habe ich nur den Pfad zur DB im OI geändert. Der Rest ist von Borland. :mrgreen:

Gruß
Hansa


LCS - Di 17.12.02 15:44

Hi
Ab Delphi 6 steht diese Funktion in der Unit Variants (vorher System) und die steht nicht in der Uses-Liste.

Gruss Lothar


hansa - Di 17.12.02 15:48

Hi,

Danke, das ging ja flott. :D So was mußte es ja sein.

Gruß
Hansa


LCS - Di 17.12.02 15:51

Vielleicht sollte man die Jungs mal darauf hinweisen, dass es Compiler-Direktiven gibt, mit denen man sowas umgehen kann :mrgreen:


hansa - Di 17.12.02 15:53

:?:


hansa - Fr 20.12.02 11:44

Hi,

wüßte mal gerne wie Ihr das so macht. Scheint ja keinen zu interessieren. Also ich habe jetzt einige Tables. Es ist schon klar, daß ich die Artikel-Table nicht brauche, um die Hausnummer eines Kunden zu ändern. Bei komplexeren Sachen (z.B. bei einer Rechnung) brauche ich aber doch mehr. Wie soll ich das denn jetzt am besten gruppieren ? Ich glaube kaum, daß es sinnvoll ist, auf jede Form Datasets usw. zu platzieren und das alles jedesmal neu zuzuordnen. Der umgekehrte Weg wäre wohl, alles irgendwie nötige in ein riesiges DataModul zu packen. Hmm, das ist mir aber auch nicht ganz geheuer.

Gruß
Hansa