Diskussion: Umstellung einer Datenbank in einem Projekt

[RWarnecke]

Den Vorteil, so wie Hansa es beschrieben hat, sehe ich auch in einem Export der bestehenden Daten. Zum einen habe ich erstmal eine Sicherung der Daten und zum zweiten kann ich dann die Exportierten Daten so anpassen, wie ich es möchte.

Ich habe gerade noch den Paradox Viewer gefunden. Auf den ersten Blick sieht das Teil garnicht schlecht aus. Werde es heute laufe des Tages es ausgibieg testen und dann hier berichten. Dieser Viewer soll nur zur Unterstützung dienen.

[nahpets]

Hallo,

eventuell schaust Du Dir mal die Komponente TBatchMove an, sie benötigt noch die BDE, was ja bei Deinem Altsystem auch der Fall ist. Mit dieser Komponenten kann man recht einfach Tabellen zwischen Datenbanken kopieren. Zum Kopieren müssen sie halt beide über die BDE erreichbar sein. Das gilt aber nur für die Kopierroutinen, die ja nur einmalig benötigt werden und ist für den späteren Zugriff auf die Zieldatenbank nicht relevant.

Die Komponente bietet auch die Möglichkeit, beim Kopieren unterschiedliche Spaltennamen zu matchen. Problemfälle kann sie in Paradoxtabellen protokollieren. Der Programmieraufwand hält sich in Grenzen, da ein Programm für viele Tabellen genutzt werden kann. Je Quell- und Zieltabelle benötigt man halt den Namen der Quell- und Zieltabelle, die Namen der "Fehler"-Tabellen und eine Stringliste mit dem Matching der Spalten (sofern hier keine 1:1-Übernahme erfolgt).
Bei einer 1:1-Übernahme kann man hiermit in eine Schleife alle Tabellen einer Datenbank kopieren, man muss nur die Tabellennamen jeweils austauschen und den Kopiervorgang starten.

Mit dieser Komponente habe ich schon Daten zwischen diversen (kleineren) Datenbanken ausgetauscht, in der Regel war die Quelle dbase oder Paradox und das Ziel Oracle oder SQL-Server.

Die Komponente bietet verschiedene Modi für die Datenübernahme, von hinzufügen, über hinzufügen und aktualisieren, reinem kopieren, reinem aktualisieren bis zum Löschen.
Hierüber dürfte auch eine Normalisierung der Tabellen möglich sein, wenn man Quelle und Ziel geschickt auswählt und so eine Quelltabelle in mehreren Schritten in die entsprechenden Zieltabellen übernimmt. Muss man im Zielsystem aber erst noch neue Schlüssel generieren, dann dürfte die Leistungsgrenze der Komponente erreicht oder überschritten sein.

http://edn.embarcadero.com/article/25620

[Sharky]

Zitat von RWarnecke:

Das würde also heißen, wenn ich zum Beispiel folgenden Code habe :

Delphi-Quellcode:

with xxQuery do 
begin
  SQL.Clear;
  SQL.Text := 'SELECT * FROM tabelle';
  Open;
  Active := true;
  Edit1.Text := FieldByName('Feld1').AsString;
{...}
  Active := false;
  Close;
end;

Dann bin ich mit einer TxxQuery besser bedient oder wie darf ich das verstehen? Ich kann noch nicht so richtig den Unterschied sehen zwischen TxxQuery und TxxDataset.

Es kommt immer darauf an was gewünscht wird.

Nehmen wir einmal an Du hast eine Tabelle mit einem Integer-Feld als ID(PK) und 30 Felder a 10Char. Davon hast Du nun 10.000 Datensätze.

In deinem Programm hast Du nun ein Grid oder so um die ersten vier Char Felder anzuzeigen (als Auswahlliste).

Bei einem SELECT * FROM tabelle (oder verwendung von TTable) werden jetzt also

(4 Byte + 30*10Byte) * 10.000 = 3.040.000 Byte geladen.

Benötigt wird für die Anzeige aber nur SELECT ID,Feld1,Feld2,Feld3,Feld4 FROM tabelle Also

(4 Byte + 4*10Byte) * 10.000 = 440.000 Byte

Wenn Du nun die Details eines Datensatzen benötigst lädst Du diese genau dann wenn Du sie benötigst.
SELECT * FROM tabelle WHERE ID = akuelleIDausAuswahlListe Das ist einer der Vorteile eines Query

[Muchacho]

Hi Sharky,

Ist Open und Active nicht das Gleiche?


Außerdem Open sollte immer „geschützt“ werden z.B.:

Delphi-Quellcode:

 try
  Open;
 except
   on E:Exception do
   begin 
    //
   end
 end;

Muchacho

[Sharky]

Hai Muchacho,

wenn Du genau hinsiehst kannst Du erkennen das der Code mit Open und Active nicht von mir ist

Zitat von Muchacho:

... Außerdem Open sollte immer „geschützt“ werden z.B.:

Habe ich, ehrlich gesagt, noch nie gemacht.

[Muchacho]

Zitat von Sharky:

Habe ich, ehrlich gesagt, noch nie gemacht.

Sharky,

solltest Du aber

Muchacho

[Muchacho]

Sharky

Du hast ein Formular mit sagen wir 10 Querys

Jetzt kriegst Du einen Anruf von einem Kunden:

„Hi, Sharky, ich kriege immer bei Öffnen des Formulars ein SQL Fehler, was ist los?“

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen?

Muchacho

[Mithrandir]

Zitat von Muchacho:

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen?

Gar nicht, denn dann fällt die eigentlich immer recht aussagekräftige SQL-Fehlermeldung weg.
Btw, Muchacho, der - Button möchte gerne benutzt werden.

[RWarnecke]

Der Sourcecode war von mir einfach nur niedergeschrieben, da es um ein kurzes einfache Beispiel ging mit TxxQuery und TxxDataset. Das ist jetzt aber auch nicht das Thema.

Auf jedenfall zeigt das Beispiel von Sharky deutlich, was man an Traffic einsparen kann, wenn man die TTable-Komponenten durch TxxQuery-Komponenten ersetzt.

[Muchacho]

Zitat von Daniel G:

Zitat von Muchacho:

Was meinst Du Sharky, wie könnte Dir [try/except/end] Block weiterhelfen?

Gar nicht, denn dann fällt die eigentlich immer recht aussagekräftige SQL-Fehlermeldung weg.
Btw, Muchacho, der - Button möchte gerne benutzt werden.

Sorry wg. Edit.

Was [try/except/end] Block an dieser Stelle betrifft irrst Du Dich gewaltig, sorry.

Manche aussagekräftige Meldungen von SQL-Server sind natürlich nur für Gott verständlich.

Darüber hinaus wäre es nicht schlecht,wenn das Formular (trotzt Fehler) weiter läuft
und nicht z.B. OnShow zusammenbricht, meinst Du nicht?

Tja

Muchacho