Datum in DB speichern mit Delphi DB Komponenten

[Salomon]

Hallo DPler,
ich arbeite mit den Delphi DB Komponenten. Nun muss ich ein Datum in der DB speichern. Welche Komponente kann ich dafür verwenden?
Eine spezielle Komponente für Datum Ein-/ausgabe habe ich nicht gefunden.

Oder sollte ich auf die DB Sensitiven Komponenten verzichten? Ich kann das ganze auch mit den "normalen" Komponenten (z.B. DateTimePicker) machen und mir daraus ein SQL Insert basteln.

Ich bin nicht sehr erfahren in der Entwicklung von DB Anwendungen. Zeugt es von schlechten Programmierstil wenn man Teils die DB Sensitiven Komponenten verwendet, und Teils auf sie verzichtet und dafür SQL Abfragen und "normale" komponenten nutzt?

Gruß
Marcus

[Bernhard Geyer]

Je komplexer Anwendungen sind desto mehr wird man DB-Sensitive Controls vermeiden. Und zwar aus folgenden Grund:

1, Nicht für alle Controls gibt es vernünftige DB-Gegenstücke
2, Der Automatische Query/Post-Mechanismus von gebundenen Datenmengen ist störend
3, Datenbankunabhängige Programmierung ist meist nur sehr schwer mit DB-Sensitiven Controls möglich

Für einfache bzw. Prototypanwendungen spricht nichts gegen DB-Sensitive Controls.

[Salomon]

Hi Bernhard,
punkt 1 und 2 kann ich auch jetzt schon bestätigen. Dann werde ich wohl häufig auf die sensitiven Komponenten verzichten.

- Empfiehlt es sich dann für jede DB Tabelle eine Routine/ Funktion zu schreiben die Daten in sie schreibt?

- Ist die Verwendung einer ADO Query Komponente für mehrere SQL Abfragen sinnvoll und den "guidlines" für DB Entwicklung entsprechend?

Und zu guter letzt ein wichtiger Punkt für mich:

- Wie geht man normalerweise mit konkurierenden Datenbank zugriffen um? Also 2 Benutzer wollen einen Datensatz nahezu zeitgleich bearbeiten. Da muss der spätere Benutzer ja eine Info bekommen das der Datensatz schon in bearbeitung ist. Am besten wer ihn bearbeitet.

Danke!

[Bernhard Geyer]

Zitat von Salomon:

- Empfiehlt es sich dann für jede DB Tabelle eine Routine/ Funktion zu schreiben die Daten in sie schreibt?

Hängt von deiner Deiner Architektur ab wie und auf welcher Ebene du Objektorientierst und auf Business-Objekte gehst.

Zitat von Salomon:

- Ist die Verwendung einer ADO Query Komponente für mehrere SQL Abfragen sinnvoll und den "guidlines" für DB Entwicklung entsprechend?

Wir haben bei unsere Anwendung (über 1 Mio Quellzeilen) keine festen Query-Komponenten sondern es wird alles dynamisch gemacht. Auch ja. Die ADO-Kompos solltet du nur bei MS SQL-Server und Access verwenden. Für alle anderen DBs gibts bessere Kompos

Zitat von Salomon:

- Wie geht man normalerweise mit konkurierenden Datenbank zugriffen um? Also 2 Benutzer wollen einen Datensatz nahezu zeitgleich bearbeiten. Da muss der spätere Benutzer ja eine Info bekommen das der Datensatz schon in bearbeitung ist. Am besten wer ihn bearbeitet.

Dazu gibt es viele Möglichkeiten und man könnte darüber dicke Bücher schreiben. Wenn du auf die Suche im Forum gehst wirst du einiges an Infos/Vorschlägen/Möglichkeiten finden.

[Salomon]

Zitat:

Hängt von deiner Deiner Architektur ab wie und auf welcher Ebene du Objektorientierst und auf Business-Objekte gehst.

Uff, das war jetzt irgendwie zu hoch für mich... Momentan habe ich ein "Datenmodul" in dem die DB Komponenten liegen. Die einzelnen Programmteile / Fenster greifen dann darauf zu und lesen oder schreiben Daten in die DB.

ADO werde ich wohl beibehalten da das ganze ja mit einem MS SQL arbeitet.

Das dynamische erstellen der DB Komponenten z.B ADOQuery gefählt mir Ich denke das werde ich auch machen. Da sind die einzelnen Module auch besser von einander abgegrenzt.

Zu den konkurierenden Zugriffen mache ich mich mal schlau. Ich stell dann sicher speziellere Fragen...

[Hansa]

Wichtig wäre mal zu wissen, was genau benutzt wird. Ansonsten gilt das :

Zitat von Bernhard Geyer:

Je komplexer Anwendungen sind desto mehr wird man DB-Sensitive Controls vermeiden. Und zwar aus folgenden Grund: ...

Für mich liegen die Gründe hauptsächlich in der Flexibilität. Setzt man da OOP-Technolgie ein, dann geht das auch ohne DB-Komponenten.

[Bernhard Geyer]

Zitat von Hansa:

Für mich liegen die Gründe hauptsächlich in der Flexibilität. Setzt man da OOP-Technolgie ein, dann geht das auch ohne DB-Komponenten.

Argument 2+3 gehen auch teilweise in diese Richtung