Filter oder SQL?

[Privateer3000]

Hi Jelly,
na bisher ini jetzt WILL ich ja auf db umbasteln.

[Jelly]

Zwei Sachen:

1. Ersetze deine For-Schleife durch ein

Delphi-Quellcode:

while not table.eof do begin
   // .. Mach was
   table.Next ;
end ;

2. Nutze nach Möglichkeit anstatt Field[0] stattdessen die Spaltennamen, denn dann weisst du auch noch in 2 Wochen was gemeint ist. Dafür gibt es die Funktion FieldByName bei allen TDataset Abkömmlingen, also auch bei deiner TTable.

[Bernhard Geyer]

Zitat von Privateer3000:

Hi Jelly,
na bisher ini jetzt WILL ich ja auf db umbasteln.

Das nocht keinen gesagt hat: Bitte nicht die BDE verwenden. Du setzt da auf ein Todes Pferd das dir bei der Verteilung des Programmes und der Stabilität Baumstämme zwischen die Beine schmeißt.

[alzaimar]

[quote="Bernhard Geyer"]

Zitat von Privateer3000:

... das dir bei der Verteilung des Programmes und der Stabilität Baumstämme zwischen die Beine schmeißt.

Wälder, ganze Wälder!

Für kleine DBF-Tabellen reicht z.B. TDBF oder auch ADO und ein ODBC-Treiber, der auf jedem neueren PC installiert ist.

Ich hab auch mit ADO und Text-Dateien gute Erfahrungen gemacht.

[mkinzler]

Oder man setzt gleich auf eine besseres DBMS

[Privateer3000]

Danke Leute,
kann man für ADO zB auch Tools wie
die Datenbankoberfläche von Delphi nutzen
um Tabellen zu erstellen?
Funktioniert das Prinzip im ADO gleich wie unter BDE?
Konnektiert ADO auch zu dbf, oder muss man eine andere
Tabellenart benutzen?

Grüße

[Bernhard Geyer]

Zitat von Privateer3000:

kann man für ADO zB auch Tools wie
die Datenbankoberfläche von Delphi nutzen um Tabellen zu erstellen?

Nein. Aber je nach verwendeter Datenbank (Access, MS SQL-Server kann man die dort angebotenen möglichkeiten verwende, oder wenn man sich mit SQL besser auskennt erzeugt man die Tabellen im Quellcode

Zitat von Privateer3000:

Funktioniert das Prinzip im ADO gleich wie unter BDE?

Welches Prinzip? Vieles ist ähnlich, aber manches sollte man bei richtigen SQL-Servern anders machen als bei Desktop-DB's wie DBase, Paradox, Access.

Zitat von Privateer3000:

Konnektiert ADO auch zu dbf, oder muss man eine andere Tabellenart benutzen?

Über die Access-Jet-Engine: Ja. Aber vergiss dbf wenn du nicht irgendwelche Altlasten pflegen musst.

[mkinzler]

Und Access am Besten auch gleich.

[hoika]

Hallo,

bis jetzt (fast) alles richtig.

Access zu benutzen ist OK,
wenn nicht Access als DB benutzt wird.

Klingt komisch, aber is so ...

Es gibt "Access Project", dabei wird Access
als Oberfläche benutzt, die DB ist der MS-SQL.

Vorteil:
Die Assistenten funktionieren alle,
Der Ausdruck kann schön konfiguriert werden.

Nachteil:
VBA, Access Basic.


Für kleine Dinge, di nur zusammengeklickt werden sollen,
kann man das benutzen.


Heiko

[Bernhard Geyer]

Zitat von hoika:

Access zu benutzen ist OK,
wenn nicht Access als DB benutzt wird.

Klingt komisch, aber is so ...

Es gibt "Access Project", dabei wird Access
als Oberfläche benutzt, die DB ist der MS-SQL.

So eine Lösung haben wir als CRM-System und findes es krottig schlecht (Langsam, Fehlerhaft, ...).
Kann aber auch an den SW-Entwicklern dieses Systems liegen. Ein Wechsel zu einem anderem System ist aber auch Aufwändig
und es müsste erst das richtige gefunden werden.

Aber das wichtigst wird sein: Ich denke in 5-10 Jahren wird Access das gleiche Schicksal wie Foxpro treffen: Es wird eingestellt werden. Wieso sollte sich MS 2 DB's leisten? Und da der Weg von Access ist die .NET-Welt auch viele Anpassungen nötig machen würde wird man es irgendwann sterben lassen.