Diskussion: Umstellung einer Datenbank in einem Projekt

[hoika]

Hallo,

wie es so schön heisst:
Ein Bild sagte mehr als 3 Worte.

Firebird - Architekturen


Heiko

[RWarnecke]

Danke Heiko, die Beschreibung werde ich mir heute Abend zu gemüte führen. Habe Sie gerade nur mal überflogen.

[RWarnecke]

Ich bin gerade dabei die Struktur der DB-Komponenten im Programm zu analysieren. Da ich nicht viel mit den DB-Kompos gemacht habe, treten gerade ein paar Fragen auf.

1. Ich weiß, dass bei einem einfachen TTable die Abfrage
   SQL-Code:

   SELECT * FROM <tabellenname>

   gemacht wird. Was passiert aber, wenn jetzt im TTable noch eine MasterSource mit angegeben ist ?
2. Bei einer TQuery ist noch die Eigenschaft Filter gesetzt. Im SQL-Text steht nur
   SQL-Code:

   SELECT * FROM tabelle1 S LEFT OUTER JOIN tabelle2 K ON (S.ID = K.ID)

   . Müsste dann für den gesetzten Filter der SQL-Befehl so aussehen
   SQL-Code:

   SELECT * FROM tabelle1 S LEFT OUTER JOIN tabelle2 K ON (S.ID = K.ID) WHERE state=2;

3. Was muss ich beachten, wenn mit MasterSource sozusagen eine Kette gebildet wurde ?

Ich muss gestehen, ich blicke da im Moment nicht so richtig durch. Ich hoffe mir kann da jemand weiterhelfen.

[hoika]

Hallo,

zu 2.
WHERE table1.state=2;

Zu allen anderen Sachen bin ich einfach überfragt.
Ich würde eh die Finger von TTable lassen.

Da alle TTable intern eh in Queries umgewamdelt werden (bei SQL-Server),
kannst du nur durch Probieren herausfinden, was passiert.


Heiko

[RWarnecke]

Hallo Heiko,

danke erstmal für Deine Antwort.

Zitat:

Zitat von hoika

Ich würde eh die Finger von TTable lassen.

Ich will ja durch die Umstellung von den TTable's wegkommen und dabei vielleicht Abfragen in Views oder Stored Procedure's setzen.

Zitat:

Zitat von hoika

Da alle TTable intern eh in Queries umgewamdelt werden (bei SQL-Server),
kannst du nur durch Probieren herausfinden, was passiert.

Das ist nicht das was ich hören wollte. :? Da ich über 30 Tabellen habe, wird das dann eher ein munteres Ausprobieren.

[hoika]

Hallo,

dann nennen wird das mal um in

Systematischen Testen ;)

DUnit ist dein Freund


Heiko

[RWarnecke]

Hallo Heiko,

ich habe mir jetzt mal DUnit runtergeladen und mir das Tutorial angeschaut. Ich habe auch den Hintergrund der Unit verstanden. Nur verstehe ich im Moment noch nicht, wie mir die Unit bei der Umstellung helfen soll, wenn ich nichtmal weiss wie das MasterSource in einer TTable funktioniert.

[hoika]

Hallo,

es geht ums Testen.

du hast doch jetzt ein "paar" DB-Methoden,
die richtige Ergebnisse liefern.

Bsp.

Delphi-Quellcode:

function Add2(const theValue: Integer): Integer;
begin
  Result:= theValue+2;
end;

Per DUnit wäre jetzt folgender Test

Delphi-Quellcode:

type
  TTestCase1 = class(TTestCase)
    published
      procedure Check_Add2;
  end;

procedure TTestCase1.Check_Add2;
var
  iValue: Integer;
  iResValue: Integer;
begin
  iValue:= 0;
  iResValue:= Add2(iValue);
  Check(iResValue=2);
end;

So sieht das auch bei deinem (originalem) DB-Code aus.

Änderst du jetzt das Add2 irgendwie ab (TTable->TQuery),
kannst du trotzdem prüfen, ob nach der Änderung immer noch
alles so läufst, wie du es erwartet hast.


Heiko

[RWarnecke]

ok, das es ums testen geht ist mir schon klar. Aber um testen zu können brauche ich ja erstmal einen Ansatz. Dieser fehlt mir, da ich bis jetzt noch nicht weiß wie und was das MasterSource im TTable bewirkt.

[mkinzler]

Die MasterSource dient zur Abbildung einer Master/Detail Beziehung; bei Änderung des aktiven Datensatzes des Masters, wird die Detaildatenmenge entsprechend gefiltert