Diskussion: Umstellung einer Datenbank in einem Projekt

[RWarnecke]

Hallo zusammen,

wenn ich in einem Programm eine Datenbank habe und diese Umstellen muss. Stelle ich mir die folgenden Fragen :

1. Worauf muss man achten ?
2. Lohnt es sich das Programm komplett neu aufzubauen ?
3. Wenn im Programm DB-Komponenten (TDBEdit, TDBLabel u.s.w.) habe, sollte ich diese ersetzen ?
4. Umstellung von TTable auf TQuery (ja/nein) ?

Ich selber würde das Programm neu aufbauen. Dabei würde ich alles auf Queries umbauen und die ganzen DB-Komponenten rausschmeissen. Das ist natürlich viel Aufwand, kann aber so am besten das Layout von den Daten trennen.

Wie würde Ihr vorgehen und unter welchen Voraussetzungen würdet Ihr was machen ?

[mkinzler]

Zu.
2.) 3.) Nicht wegen der Umstellung
4.) Auf jeden Fall

[RWarnecke]

Zu 4.):
Nur was für eine Abfrage habe ich bei TTable. Ich entsimme mich, dass das immer eine Abfrage auf die komplette Tabelle ist. Liege ich damit richtig oder falsch ?

Welche Vorteil habe ich dabei, wenn ich die Komponenten TQuery-->TDataSource-->TDBEdit verbinde ? Irgendwie sehe ich darin keinen Vorteil. Ich bin der Meinung, dass wenn ich die Daten vom TQuery diekt in ein TEdit zum Beispiel schreibe mehr davon habe und auch flexibler bin.

[mkinzler]

Ein TTable hat bei einem richtigen DBMS die Abfrage

SQL-Code:

select * from <Tabelle>;

Also alle Felder und alle Records.

Zitat:

Irgendwie sehe ich darin keinen Vorteil. Ich bin der Meinung, dass wenn ich die Daten vom TQuery diekt in ein TEdit zum Beispiel schreibe mehr davon habe und auch flexibler bin.

Das ist ja auch so. Ich meinte ja, dass dies beim Austausch des DBMS nicht notwendig ist. Unabhängig davon kann es aber durchaus sinnvoll sein.

[joachimd]

Zitat:

Zitat von mkinzler

Ein TTable hat bei einem richtigen DBMS die Abfrage

SQL-Code:

select * from <Tabelle>;

Also alle Felder und alle Records.

kleiner Kommentar hierzu: das gilt nicht für alle, sondern nur für die, die reines SQL zulassen und sonst nichts. Der ADS zB bietet auch über die Client/Server Engine echtes ISAM an ... damit kann man bei solcherlei Abfragen um viele Größenordnungen schneller sein als mit reinem SQL (und - wie bei den meisten - einem FETCH ALL, wenn man nur den letzten Datensatz anzeigen möchte, ohne gleich die Query zu schliessen und neu zu erstellen).

[mkinzler]

Zitat:

kleiner Kommentar hierzu: das gilt nicht für alle, sondern nur für die, die reines SQL zulassen

Das hatte ich "richtigen" DBMS gemeint.
Bei Desktop Datenbanken wird hingegen ein TQuery auf eine TTable abgebildet.

[hoika]

Hallo,

zu aller erst mal die Frage,
welche Datenbank der Ausgangspunkt ist.
Ich schätze ja mal Paradox oder DBase (?)
Dann geht es hier also auch um die Ablösung der BDE ...


1. Worauf muss man achten ?

- Keine Fehler einbauen, d.h. die DB-Funktionen sollten Unit-Tests haben (dunit)
- Performance-Tests mit "grosser" DB
Mit gross meine ich, das in der Personal-Tabelle nicht eine Person drinsteht,
sondern der normale Standard (was auch immer das bei dir ist)


2. Lohnt es sich das Programm komplett neu aufzubauen ?

- Kommt auf das Programm an.


3. Wenn im Programm DB-Komponenten (TDBEdit, TDBLabel u.s.w.) habe, sollte ich diese ersetzen ?

- Habe ich nie benutzt.


4. Umstellung von TTable auf TQuery (ja/nein) ?

Habe ich genauso gemacht. Im Nachhinein war es ein Riesenaufwand (vor allem das Testen)
Ich habe praktisch den kompletten DB-Code neugeschrieben.
Es wurden dann auch "spezielle" SQL-Konstrukte benutzt,
wie z.B. joins, die mit Paradox wegen der Performance nicht funktionierten.


Der Aufwand ist auf jeden Fall nicht zu unterschätzen,
wobei natürlich das Original-Programm eine grosse Rolle spielt
(vorhandene Trennung DB / Form).

Ich habe mir noch eine Wrapper-Komponente TQuery (BDE) -> TDataSet (FIBPlus)
gebaut, die die paar fehlenden BDE-Query-Befehle (z.B. QueryIsEmpty)
umgesetzt hat.


#Moderator#
Bitte nach Datenbanken verschieben.


Heiko

[joachimd]

Zitat:

Zitat von mkinzler

Das hatte ich "richtigen" DBMS gemeint.

Ich möchte hier nicht große Diskussionen und Grabenkämpfe vom Zaun brechen, aber was unterscheidet für Dich ein "richtiges" von einem "falschen" (oder ist das der falsche Begriff) DBMS? Ein DBMS (also Datenbank Management System) ist generell gesagt, ein System, das dabei hilft, Datenbanken (also erstmal unabhängig von deren Implementierung - damit fällt auch eine Sammlung von Textdateien darunter!) zu verwalten.
Ich muss leider allzuoft erleben, dass solcherlei Aussagen gebetsmühlenartig heruntergeleiert werden, ohne dass sich die Leute Gedanken darüber machen - nur weil es solche Schwergewichte wie IBM, Oracle, MS - und auch Sybase (mit der ASE) vorbeten.

[DP-Maintenance]

Dieses Thema wurde von "mkinzler" von "Programmieren allgemein" nach "Datenbanken" verschoben.
Geht um Datenbanken

[mkinzler]

Bei den meisten DBMS handelt es sich um SQL-Server, von denen ging ich aus. Im Kontrast hierzu sah ich Desktop Datenbanken, also ein System ohne Server, wo alle Clients direkt auf die Datei(en) zugreifen und sich über Sperren synchronisieren.

[Muchacho]

Zitat:

Zitat von joachimd

[Ich muss leider allzuoft erleben, dass solcherlei Aussagen gebetsmühlenartig heruntergeleiert werden, ohne dass sich die Leute Gedanken darüber machen - nur weil es solche Schwergewichte wie IBM, Oracle, MS - und auch Sybase (mit der ASE) vorbeten.

Jawohl!

und weiter:

RWarnecke hat hier ganz einfache Frage gestellt und gleich bricht hier eine Diskussion über Zukunft unseres Planeten aus.

Was ist besser Query oder Table, was ist DBMS etc…?

Man sieht sofort, dass hier Theoretiker am Werk sind (ist nicht böse gemeint!)

Die richtige Fragestellung wäre:


Wie groß ist das Programm?

Wie viel Zeit hat man für die Umstellung?

Ist das eine professionale Anwendung oder programmiert man zu Hause (Zeitdruck?)?

Muss man eventuelle Kunden mit Update beliefern?

Ist BDE im Spiel?

Was für eine Datenbank benutzt man jetzt?


Und noch viele andere Fragen.

Eine Umstellung eines Programms ist keine 10 Minuten – Forum Entscheidung.


Und hier meine Antwort auf die Frage:

Was ist besser Query oder Table?

Es hängt immer davon ab, was ich erreichen möchte und eine pauschal Antwort ist hier nicht möglich
es seitdem kann man mir im Gegenzug diese Frage beantworten:


Was ist besser Kartoffel oder Reis?


Muchacho

[mkinzler]

Ich bin halt ein Theoretiker und vielliecht auch ein Vollidiot.
Wenn einer etwas fragt, antworte ich halt. Mein Fehler werde das Feld jetzt den Profis überlassen, welche sich wirklich auskennen und in der Zukunft meine Fresse halten!

[Muchacho]

Zitat:

Zitat von mkinzler

Ich bin halt ein Theoretiker und vielliecht auch ein Vollidiot.
Wenn einer etwas fragt, antworte ich halt. Mein Fehler werde das Feld jetzt den Profis überlassen, welche sich wirklich auskennen und in der Zukunft meine Fresse halten!

@mkinzler

Wie ich schon betont habe: Ist nicht böse gemeint.

Ich weiß schon seit langem, dass Du sehr gut bist, aber in den Software Häuser spielt die Music manchmal ganz andere Melodie!

Nichts für ungut

Muchacho

[joachimd]

Zitat:

Zitat von mkinzler

Bei den meisten DBMS handelt es sich um SQL-Server, von denen ging ich aus. Im Kontrast hierzu sah ich Desktop Datenbanken, also ein System ohne Server, wo alle Clients direkt auf die Datei(en) zugreifen und sich über Sperren synchronisieren.

hmmmm....wie passt in dieses Bild jetzt in zB Embedded FireBird? Der ist nämlich ein echter "SQL Server", aber trotzdem eine Desktop Datenbank :( Die Welt ist leider nicht schwarz (BDE/Paradox) und weiß (Oracle), es gibt durchaus aus viele, viele dazwischen.
nix für ungut...ich breche die Diskussion jetzt ab, wollte eigentlich auch gar nicht groß diskuttieren, sondern nur die Unklarheiten, die dadurch beim Fragesteller sicherlich aufkommen, richtigstellen.
Mach Du bitte trotzdem weiter...bitte,bitte,bitte ;)

[joachimd]

Zitat:

Zitat von RWarnecke

1. Worauf muss man achten ?
2. Lohnt es sich das Programm komplett neu aufzubauen ?
3. Wenn im Programm DB-Komponenten (TDBEdit, TDBLabel u.s.w.) habe, sollte ich diese ersetzen ?
4. Umstellung von TTable auf TQuery (ja/nein) ?

Ein bisschen was zum Thema: Ein(!) möglicher Weg weg von BDE/Paradox und hin zu einem Client/Server (und natürlich auch SQL sprechenden) System, könnte der ADS sein. Auf der diesjährigen CodeRage habe ich einen Vortrag dazu gehalten. Die Aufzeichnung gibt es hier. Der Aufwand ist natürlich immer vom bestehenden System abhängig, kann aber durchaus auch innerhalb weniger Minuten vonstatten gehen.

[RWarnecke]

Hallo Joachim,

ich habe Deinen Vortrag auf der Roadshow in Stuttgart gesehen und war davon echt begeistert. In meinem konkreten Fall geht es um eine BDE die abgelöst werden soll. Ich habe auch schon mit eurem Vertrieb telefoniert bezüglich Lizenzen etc. Das Gespräch hat mich ein wenig abgeschreckt, die ADS zu nehmen. Deshalb bin ich auch gerade dabei mir die Migration zu anderen DBMS anzuschauen.

Desweiteren geht es mir darum, wie und welchen Weg ich gehe für die Umstellung. Der Weg sollte unabhängig davon sein, egal auf welches System migriert wird.

[hoika]

Hallo,

also mein Weg weg von Paradox war.

1. Paradox durch Interbase6 / BDE / SQL-Links ersetzt

2. Ersatz aller langsamen TTable-Methoden durch TQuery
Langsam wurde durch Test mit einer "fully populated" DB gemacht
Danach gab es einen Mischmasch aus TTable und TQuery

3. Schrittweiser Ersatz der TTable durch TQuery
Ich hab da einfach bei meinen kleinsten DB-Units angefangen

4. Ersatz aller TQuery durch TMyQuery
TMyQuery = class(TQuery)
TMyQuery ist also immer noch eine BDE-TQuery

In diesem Zuge wurden alle Forms von direkten TMyQuery bereinigt,
jaja, RAD war halt früher so

5. Mein Clou ;)
{$IFDEF BDE}
TMyQuery=class(TQuery)
{$ELSE}
TMyQuery=class(TpFIBDataSet)

// fehlende Methoden nachbauen, u.a. die AutoCommits der BDE
{$ENDIF}

1.-5. TESTEN / TESTEN / TESTEN


Und warum dieser ganze Aufwand ?
Das Programm befindet sich im Einsatz und muss während der Umstellung
weiterhin erweitert/gepflegt werden.

Hm, Zeitaufwand.
Angefangen, als IB6 Opensource geworden ist ...
(Der reine DB-Code sind etwa 750.000 Zeilen).

Ende: bald ...

Um noch mal auf "richtige Datenbanken" zu kommen.

Paradox zerschiesst im Mehrbenutzerbetrieb (ausser Novell-Server)
regelmäßig seine Indizes (index out of date).
Der Absturz eines Clients während des Schreibens führ oft zu kaputter Tabelle
(Die Datei ist beschädigt, aber nicht der Vorspann).

Das ist für mich dann keine "richtige Datenbank" mehr.


Heiko

[RWarnecke]

Hallo Heiko,

danke für die Beschreibung wie Du die Anwendung umgestellt hast. Auch so hatte ich es mir vorgestellt. Der einzigste Vorteil bei mir wäre, ich brauche bis zum jetzigen Zeitpunkt keinen Paralellbetrieb zu garantieren.

Daszu habe ich noch eine Frage, wie hast Du die Tabellen umgestellt ? Manuell oder mit einem Tool ?

[mkinzler]

In deinem Fall bietet es sich an, die Datenbank neu zu entwerfen. So kannst du die erweiterten Features des neuen DBMS besser nutzen. Zudem waren die meisten Paradox&Co Datenbanken die mir bisher untergekommen sind, alle wenig bis garnicht normalisiert und hatten nur teilweise richtige Schlüssel. Ich persönlich würde bei datenbezogenen Schlüsseln auf künstliche umstellen.

[generic]

Normal ist das Programm von der Datenbank unabhängig.

Du solltest Funktionen aufrufen welche sinngemäß sagen:

Code:

HoleKunde()
SpeichereKunde()
LöscheKunde()

Generell sollte es deinen Programm egal sein, was innerhalb der Funktionen passiert.
Hauptsache deine Kundenobjekte werden gefüllt.

Wenn du diese Funktionen nun über ein Interface oder in einer passenden Objekt Vererbung nutzt,
dann lässt sich die Datenbank einfach austauschen.

Delphi-Quellcode:

TBasisPersistenz = class
  function HoleKunde(Kundennummer: cardinal): TKunde; abstract;
  procedure SpeichereKunde(K:TKunde); abstract;
  procedure LöscheKunde(K:TKunde); abstract;
end;

TMSSQL = class(TBasisPersistenz);

TRESTSQL = class(TBasisPersistenz);

TMYSQL = class(TBasisPersistenz);

Mit einem Interface sieht das leicht anders aus, funktioniert aber genau so.
Ein Interface kann bei Unit-Testing Vorteil haben.

Vorteil der Methode, du kannst z.B. auch REST-Services nutzen.
Einfach die Klasse austauschen und die Welt zum laden, löschen und speichern ist offen.

[hoika]

Hallo,

von Hand, schön zu Fuss.
Und nach jedem Umbau TESTEN !!!

Das Rüberschieben habe ich für Anfangstest per IBDataPump gemacht.

Zu Paradox / künstliche Schlüssel.
Einspruch Euer Ehren ;)

Gerade meine Nutzung des AutoInc als künstlicher Schlüssel war ein Grund,
warum ich nicht gross an der Datenstruktur was machen musste.

Id Autoinc -> Id Integer


Aber MKinzler hat trotzdem "etwas" Recht ;)

Manche Datenstruktur in meinem Programm wurde nur deshalb so anlegt,
weil es unter Paradox nicht anderes oder sehr schwer ging.


Heiko

PS:
auf IBPhoenix.com gibt es 2 interessante Artikel Pdx->Interbase
"My lock file has grown too large"
"Pdx->Interbase in 40 days"

[HeikoAdams]

Zu 4:
Es gibt IMHO zwei gute Gründe, auf TTable Kompos zu verzichten.
1) Die Dinger dienen eigentlich nur der Abwärtskompatibilität zur BDE
2) TTables machen im Prinzip ein

SQL-Code:

SELECT * FROM <Tabelle>

und fragen parallel noch sämtliche Informationen zu allen Spalten der Tabelle ab, was bei großen Tabellen mit vielen Datensätze eine echte Bremse sein kann.

[Hansa]

Moin,

der Fragesteller ist wohl eher an Erfahrungen interessiert. Wo es hakt usw. Hierzu mein Bericht. Im Prinzip mache ich das auch ungefähr so wie Hoika. Zuerst muss man ja mal an die alten DB-Daten rankommen. Egal ob BDE oder sonstwas. Jetzt hatte ich da auch mit Datapump und sonstigen Tools rumexperimentiert. Oder mit EXTERNAL FILE in Firebird. Sieht auf den ersten Blick schön aus, aber der Krempel macht IMHO im Endeffekt mehr Ärger, als er nützlich ist.

Ich bin dann kurzerhand hingegangen und habe die Daten zuerstmal quasi 1:1 in normale Textdatei exportiert. Zuerst als CSV. Und was zu erwarten war : egal welches Trennzeichen, irgendwo war es trotzdem in einem Feld. Dann Test mit festen Feldlängen. Das CSV-Problem war zwar weg, aber es tauchten Felder auf, die beschädigt waren. Wohl durch Stromausfälle etc. Jetzt hat man da aber ellenlange Textzeilen und kriegt vielleicht noch relativ leicht raus, welche Zeile das Problem verursacht, aber nicht wo in der Zeile genau. Auf Dauer auch nicht empfehlenswert.

Letztenendes mache ich das mittlerweile so : jedes alte Feld kommt in extra Zeile einer Textdatei. Auf der Delphi/FB-Seite lese ich die dann einfach per readln (..); und übergebe das Ganze mit FieldByName usw. Ist jetzt da ein unlogisches Feld drin, z.B. ' ' wo integer erwartet wird, dann bleibt Delphi zumindest mal in der entsprechenden Zeile des Import-Programms stehen. Ist das Feld klar, dann lasse ich das Export-Programm genau dieses kaputte Feld anzeigen. Man könnte auch die Textdatei direkt danach untersuchen. Aber das sind normalerweise dann wegen "pro Feld eine Zeile" zu viele Zeilen.

Ist die alte DB in keinster Weise normalisiert, dann wirds aber echt kritisch. :mrgreen:

Zeitaufwand schätze ich mal auf max. 3 Tabellen pro Tag, also Programmierung der jeweiligen Export/Import-Programme. Die Zeit, die die Programme zum Ablauf brauchen nicht eingerechnet ! Mehr geht kaum. Es ist schon viel Handarbeit.

[RWarnecke]

Bis bisheriges Resüme aus den ganzen Antworten ist in Stichpunkten zusammengefasst :

• Alle Tabellen von Hand umstellen auf das neue DBMS
• Alle TTable umstellen auf Query (z.B. TQuery oder TUniQuery)
• Bei der Umstellung auf Query als ersten Weg erstmal ein SELECT * FROM <tabelle> machen, im Nachgang wenn es funktioniert nachkontrollieren ob es Optimierungsmöglichkeiten (Views Stored Procedures etc.) gibt.
• Zusätzlich zu der Umstellung drauf achten, dass man Daten vom Layout trennt (Datenmodul, Klasse oder Interface wie in Beitrag #20).

So würden jetzt meine 4 großen Hauptpunkte aussehen, für eine Umstellung von Datenbank A nach B.

Zitat:

Zitat von Hansa

Letztenendes mache ich das mittlerweile so : jedes alte Feld kommt in extra Zeile einer Textdatei. Auf der Delphi/FB-Seite lese ich die dann einfach per readln (..); und übergebe das Ganze mit FieldByName usw. Ist jetzt da ein unlogisches Feld drin, z.B. ' ' wo integer erwartet wird, dann bleibt Delphi zumindest mal in der entsprechenden Zeile des Import-Programms stehen. Ist das Feld klar, dann lasse ich das Export-Programm genau dieses kaputte Feld anzeigen. Man könnte auch die Textdatei direkt danach untersuchen. Aber das sind normalerweise dann wegen "pro Feld eine Zeile" zu viele Zeilen.

Das hier hört sich nach einer sehr guten Idee an. Zumal man dann auch DBMS unabhängig ist, wenn man sich das Import/Export Programm gleich so aufbaut.

Zitat:

Zitat von Hansa

Zeitaufwand schätze ich mal auf max. 3 Tabellen pro Tag, also Programmierung der jeweiligen Export/Import-Programme. Die Zeit, die die Programme zum Ablauf brauchen nicht eingerechnet ! Mehr geht kaum. Es ist schon viel Handarbeit.

Da ich das nicht jeden Tag mache, würde ich hier eher hergehen und 2 Tabellen pro Tag sagen.

[Hansa]

Zitat:

Zitat von RWarnecke

Da ich das nicht jeden Tag mache, würde ich hier eher hergehen und 2 Tabellen pro Tag sagen.

Sagen wir mal so : sollte es gelingen auf die beschriebene Art und Weise die erste mittelgrosse Tabelle nach FB zu exportieren, da gehe ich mal eher von 3 Tagen aus. Für erste Tabelle, wohlgemerkt. :mrgreen: Der Teufel liegt da im Detail und das hält zumindest anfangs gewaltig auf. Mal andersrum gesagt : habe hier eine alte DB mit 60 Tabellen. Bin am überlegen, die wie beschrieben umzustellen. Alternative wäre, zumindest Grunddaten von Hand einzufügen. Allerdings : das Endprogramm für die Daten an sich ist schon soweit fertig, egal wo die jetzt genau herkommen und die FB-DB steht auch. Es müssten allerdings 120 Programmchen gemacht werden. Schätze ca. 2-3 Wochen insgesamt. :zwinker: Aber nur, weil da viel abgekupfert werden kann. D.h. Grundgerüst ist ja immer gleich und es gilt lediglich die entsprechenden Datasets und Felder anzupassen.

Davon mal abgesehen : was soll das dauernd mit dem TTable, TQuery etc. ? :gruebel: Das ist doch alles längst überholt. Bei mir gibts lediglich aus Komp.Gründen eine Query. Normal wäre TDataset-Abkömmling.

[RWarnecke]

Zitat:

Zitat von Hansa

Davon mal abgesehen : was soll das dauernd mit dem TTable, TQuery etc. ? :gruebel: Das ist doch alles längst überholt. Bei mir gibts lediglich aus Komp.Gründen eine Query. Normal wäre TDataset-Abkömmling.

Was ist jetzt da der Unterschied ? Da ich bei den ganzen Komponenten von AnyDAC, UniDAC, FIBPlus u.s.w. immer wieder eine Query-Komponente sehe.

[Hansa]

Zumindest bei FIBPlus ist sie wohl nur dazu da, dass die BDE-Leute nicht zuviel Angst kriegen. :mrgreen:

[RWarnecke]

Zitat:

Zitat von Hansa

Zumindest bei FIBPlus ist sie wohl nur dazu da, dass die BDE-Leute nicht zuviel Angst kriegen. :mrgreen:

Nett, aber worin liegt jetzt genau der Unterschied zwischen einer Query und einer Dataset Komponente ?

[mkinzler]

Es kommt hierbei aber auch an, was man benötigt. Ein TxxDataSet hat viel mehr Features als ein TxxQuery aber auch einen größeren Overhead.
Wobei die TIBCQuery von IBDAC eine echtes DataSet in Hansas Sinne ist.
Ein TxxDataSet bietet sich an, wenn du mit <Kompo>.Append()/.Insert(), .Delete() usw. arbeiten willst.

[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.

[mkinzler]

Zitat:

Dann bin ich mit einer TxxQuery besser bedient oder wie darf ich das verstehen?

Wenn dir eine unidirektionale Datenmenge reicht ja.

[RWarnecke]

Ihr verwirrt mich jetzt völlig. :gruebel: :gruebel: :gruebel: :gruebel: :gruebel: :gruebel:

Wenn ich bis jetzt etwas neu aufgebaut habe, habe ich bis jetzt immer eine TxxQuery Komponente genommen und bis jetzt keinerlei Problem gehabt. Verstehe ich das jetzt richtig, bei einer TxxQuery habe ich eine unidirectionale Datenmenge und bei einem TxxDataSet habe ich eine directionale Datenmenge ? Der Unterschied ist nun, ich brauche bei einer TxxDataSet-Komponente nichtmehr den ganzen Klimbim drum herum wie bei einer TxxQuery ? Damit kann ich dann die Daten vom TxxDataset abgreifen wo ich will, sofern die Eigenschaft Active auf True ist oder ?

[Hansa]

Das hier müsste reichen :

Delphi-Quellcode:

with xxDataSet do 
begin
  Close;
  SelectSQL.Text := 'SELECT * FROM tabelle';
  Open;
  Edit1.Text := FieldByName('Feld1').AsString;
{...}
end;

[Der.Kaktus]

Hallo,



A:Worauf muss man achten ?

B:Lohnt es sich das Programm komplett neu aufzubauen ?

C:Wenn im Programm DB-Komponenten (TDBEdit, TDBLabel u.s.w.) habe, sollte ich diese ersetzen ?

D:Umstellung von TTable auf TQuery (ja/nein) ?

hier ein paar Gegenfragen: :wink:


zu A: warum wechselst Du(musst??) die Datenbank? ("never Change a running System")
zu B: gab es Probleme vorher?..Geschwindigkeit etc.?
zu C: warst Du (Kunde)unzufrieden mit der "ehemaligen"?
zu D: ist es noetig?

ich habe persoenlich einmal gewechselt..das war von BDE auf eine Netzwerkfaehige..dies war "noetig" (wegen sterben der BDE)..aber ansonsten????

[alzaimar]

Zitat:

Zitat von Der.Kaktus

"never Change a running System"

Wenn das jeder beherzigen würde, wären wir immer noch Aminosäuren im Ozean. :mrgreen:

[Hansa]

Zitat:

Zitat von Der.Kaktus

..das war von BDE auf eine Netzwerkfaehige..dies war "noetig" (wegen sterben der BDE)..aber ansonsten????

Aber RWarnecke soll langsam aber sicher mit der BDE untergehen, oder wie ? :shock:

[Der.Kaktus]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Der.Kaktus

"never Change a running System"

Wenn das jeder beherzigen würde, wären wir immer noch Aminosäuren im Ozean. :mrgreen:

gilt ja nur fuer "old" Programme ;-)

[Der.Kaktus]

Zitat:

Zitat von Hansa

Zitat:

Zitat von Der.Kaktus

..das war von BDE auf eine Netzwerkfaehige..dies war "noetig" (wegen sterben der BDE)..aber ansonsten????

Aber RWarnecke soll langsam aber sicher mit der BDE untergehen, oder wie ? :shock:

ich hab nix von BDE bei ihm gelesen :gruebel:

[RWarnecke]

@Kaktus :
Es ist notwenig, da das Programm für Windows VISTA und 7 lauffähig gemacht werden muss. Deshalb der Wechsel von BDE nach einem anderen DBMS.

@Hansa:
Ich sehe da keinen Unterschied zwischen Deinem Sourceocde und meinem. Aber ich habe jetz mal ein wenige in Google und Wikipedia gesucht. Korrigiert mich bitte, wenn ich falsch liege. Wenn ich das ganze jetzt richtig verstanden habe ist der Unterschied zwischen TxxQuery und TxxDataSet folgender :
Die TxxQuery-Komponente sendet die Daten nur an die Datenbank und dient nur als Sender, wobei TxxDataSet als Sender und Empfänger dient. Ich kann also mit beiden Komponenten das gleiche machen (SELECT, INSERT u.s.w.). In der Unterschied in der Funktionsweise zwischen TxxQuery und TxxDataSet liegt im nur Senden und Senden/Empfangen. Wobei das Empfangen dann das Ergebnis ist, ob die Daten richtig angekommen sind oder nicht.

Edit

Zitat:

Zitat von Der.Kaktus

ich hab nix von BDE bei ihm gelesen :gruebel:

Wo wurden den TTable und TQuery hauptsächlich eingesetzt ? Ich kenne die beiden Komponenten nur für die BDE.

[Der.Kaktus]

Zitat:

Zitat von RWarnecke

@Kaktus :
Es ist notwenig, da das Programm für Windows VISTA und 7 lauffähig gemacht werden muss. Deshalb der Wechsel von BDE nach einem anderen DBMS.

OK, Sorry...BDE habch ueberlesen...also Tip..wenn Du einfache Methode suchst bestehenden Code(BDE) zu nutzen(wenige Aenderungen)..schau Dir mal Absolute Database an..ich hatte erst kbmMemtable(weniger <10000) Datensaetze..aber selbst die Umstellung war mit Aenderung (Open, Close) sehr einfach.