Datenbank mit formblatt überarbeiten

SeboStone

Ich möchte gerne mal denjenigen sehen der mit SQL auf eine lokalen (Paradox-) Tabelle zugreift, damit ich mal so richtig lachen kann! Aber das war ja hier auch nicht klar geäussert.

Weiss jemand wie man ein

Table->Insert();

abbricht, z.B. nach einer Exception? Also z.B. ein

Table->Post();

nicht erwünscht ist oder auch nicht geht, weil sonst die DB nicht mehr konsistent ist. Sprich: ich suche eine Art Rollback-Funktion (Tabelle wird nicht gecached!), hat jemand eine Ahnung? Ich hab' in der Hilfe leider nichts passendes gefunden oder übersehen.

Sebo

Alexander Kempf

SeboStone schrieb:

Ich hab' in der Hilfe leider nichts passendes gefunden oder übersehen.

Dann schau Dir doch mal die Hilfe zu TDatabase an.

Gruß,

Alexander

SeboStone schrieb:

Ich möchte gerne mal denjenigen sehen der mit SQL auf eine lokalen (Paradox-) Tabelle zugreift, damit ich mal so richtig lachen kann!

Dann fang mal an zu lachen. Ich greife grundsätzlich nur mit 'SQL' auf meine Paradoxtabellen zu. Bei Paradox ist der Unterschied, ob über TTable oder TQuery zugegriffen wird. Wird TQuery verwendet muss man auch SQL-Anweisungen in der Query verwenden. Die Verwendung von TQuery ist natürlich etwas komplexer, aber ist auch deutlich flexibler.

Vielleicht ist Dir ja nicht klar was SQL ist? SQL ist im Prinzip eine Scriptsprache, die alle Datenbanken verstehen. Auch wenn die Datenbanken vielleicht nur eine Teilmenge des Standards unterstützen, wie z.B. Paradox mit LocalSQL.

Was Du suchst sind Transaktionen. Und dies ist abhängig von der verwendeten Datenbank und den Zugriffskomponenten.

Grüße Jochen

KlausB

Hallo

@SeboStone
:p
lach ruhig weiter - auch ich greife immer per SQL auf jede Datenbank zu
noch flexiblerer Zugriff ist doch fast unmoeglich

Versuch dochmal statt einer Paradox-DB eine andere DB zu verwenden
(umstellung auf neue DB / und das ohne SQL)

MfG
Klaus

SeboStone

SQL ist ein mächtiges Werkzeug, aber bei lokalen Datenbanken den Umweg über SQL? Und warum sollte man erst eine lokale Datei-basierende DB like Paradox benutzen und dann umstellen? Vor allem wenn die wirklichen DBMS viel leistungsfähiger (Funktionsumfang, SQL-Implementierung, speed, etc.) sind? Warum dann nicht gleich was richtiges nehmen? Zu Testzwecken? Schlechte Wahl, mit den Ergebnissen kann man dann sowieso nicht wirklich auf andere DBMS schliessen.
Ansonsten gebe ich Dir recht, eine Umstellung würde bedeuten fast alles neu zu programmieren. Aber das sollte man eigentlich schon vorher wissen. Nur wenn man viele verschiedene DBs anbieten will ist SQL das auch für lokale DBs der richtige Weg, finde ich.

Sebo

dschensky

Alexander Kempf schrieb:

Dann schau Dir doch mal die Hilfe zu TDatabase an.

...oder noch besser: TDataSet- damit Du nicht umsonst suchst

dschensky schrieb:

Alexander Kempf schrieb:

Dann schau Dir doch mal die Hilfe zu TDatabase an.

...oder noch besser: TDataSet- damit Du nicht umsonst suchst

Die Frage war wie man einen Rollback macht. Und da finde ich den Hinweis auf TDatabase und Transaktion nicht falsch?!?

SeboStone

@Joe_M.:

Ha, Dich hab' ich ja glatt vergessen! Ich glaub', ich weiss etwas besser was SQL ist, im speziellen SQL92. Leider immer noch der Standard und das auch nicht unbedingt in jedem DBS vollständig implementiert. Die neuste SQL Sprache ist SQL99. So, und jetzt übersetze mal SQL (Structured Query Language)! Was sagt uns das? Dein

SQL ist im Prinzip eine Scriptsprache, die alle Datenbanken verstehen

steht dem Schwachsinn nahe! Das heisst, Du weisst nicht was SQL ist, also halte Dich zurück. Übrigens gibt es sehr sehr viele Datenbanken, die kein SQL verstehen! Was meinst Du warum Du Query-Komponenten brauchst um eine lokale Paradox, dBase oder sonstiges über SQL ansprechen kannst?! Die Query-Komponenten übernehmen die Aufgaben eines DBMS, das ist fast der wichtigeste Bestandteil einer richtige DB - lokale DBS haben sowas nicht. Ansonsten gibt es noch eine ganze Reihe großer und wichtiger DBS die ebenfalls kein SQL verstehen.

Hier noch ein einige Bestandteile der SQL-Sprache:

- Datendefinition (DDL)
- Datenmanipulation (DML)
- Datenkontrolle (DCL)

Ach ja versuche mal ein paar spezielle Dinge mit Deinen lokalen Datenbanke z.B. "stored procedure" oder Trigger, etc. (wenn Du doch was von SQL verstehst wirst Du was finden). Ich hab's nicht ausprobiert und lass' mich auch gerne vom Gegenteil überzeugen, aber ich glaube nicht, dass die Query-Komponenten das mit den lokalen File-basierten DBS leisten kann. Wie gesagt, ich lass' mich gerne vom Gegenteil überzeugen.

Aber sonst hast Du recht, SQL ist sehr viel flexibler. Trotzdem ist die Frage ob sich SQL hier überhaupt lohnt! Nur um ein paar Daten in eine Tabelle zu quetschen - ganz bestimmt nicht. Wenn Du aber mit (outer) joins und komplexen Abfragen, etc. arbeitest ist SQL die bessere Lösung - keine Frage.

Ansonsten habe ich gefragt, wie ich eine "ART" Rollback mit der TTable-Komponente machen kann, falls es das überhaupt geht. Wenn nicht, war meine Frage wie ich ein Table->Insert() abbreche ohne eine Fehlermeldung zu bekommen, oder eine Inkonsitenz zu riskieren. Ich war vielleicht nicht ganz deutlich.

Sebo

Jansen

Für alle:
Bitte auf den Tonfall achten, die Diskussion soll doch sachlich bleiben.
Insbesondere, da sich das Ganze schon bedenklich vom ursprünglichen Thema des Threads wegbewegt ...

@Sebo:
Bitte entschuldige, wenn ich Dich unterschätzt haben sollte, aber Deine bisherigen Fragen / Postings haben den Schluß nahegelegt, dass Dein Wissen begrenzt ist.

Alexander Kempf

Joe_M. schrieb:

Deine bisherigen Fragen / Postings haben den Schluß nahegelegt, dass Dein Wissen begrenzt ist.

Wessen Wissen wäre das nicht?

SeboStone schrieb:

Die Query-Komponenten übernehmen die Aufgaben eines DBMS

Ohne das überprüft zu haben, glaube ich das nicht so richtig. Eher vorstellen könnte ich mir, daß die BDE diese Aufgabe
übernimmt, oder ODBC (über einen entsprechenden Treiber).

SeboStone schrieb:

das ist fast der wichtigeste Bestandteil einer richtige DB

Zumindest für Anwendungsprogrammierer.

SeboStone schrieb:

lokale DBS haben sowas nicht.

Also meine lokale dateibasierte Sybase DB hat selbstverständlich einen (lokalen) Server. Bei Access funktioniert das -
meines Wissens - über einen ODBC-Treiber, den man ja durchaus als "Server" auffassen kann. Was Access fehlt, ist der
echte Mehrbenutzerbetrieb.

SeboStone schrieb:

Ansonsten gibt es noch eine ganze Reihe großer und wichtiger DBS die ebenfalls kein SQL verstehen.

Das würde mich mal (wirklich) interessieren. Welche Beispiele hast Du da zur Hand?

SeboStone schrieb:

Ach ja versuche mal ein paar spezielle Dinge mit Deinen lokalen Datenbanke z.B. "stored procedure" oder Trigger, etc. Ich hab's nicht ausprobiert und lass' mich auch gerne vom Gegenteil überzeugen, aber ich glaube nicht, dass die Query-Komponenten das mit den lokalen File-basierten DBS leisten kann.

Mit Sybase (wie schon gesagt dateibasiert) funktionieren sowohl Trigger als auch stored procedures einwandfrei. Mit
Access habe ich nicht richtig viel Erfahrung, aber stored procedures werden von Acces, glaube ich, unterstützt.

SeboStone schrieb:

Aber sonst hast Du recht, SQL ist sehr viel flexibler. Trotzdem ist die Frage ob sich SQL hier überhaupt lohnt! Nur um ein paar Daten in eine Tabelle zu quetschen - ganz bestimmt nicht. Wenn Du aber mit (outer) joins und komplexen Abfragen, etc. arbeitest ist SQL die bessere Lösung - keine Frage.

Das sehe ich eigentlich eher umgekehrt. Einfache insert- oder update-Statements funktionieren fast überall. Bei Joins
mussten wir hier relativ viel unternehmen, um sowohl Informix als auch Sybase zu Outer-Joins zu bewegen. Wenn man das
einfach mit Komponenten lösen kann, hast Du Dir viel Arbeit gespart.

SeboStone schrieb:

Ansonsten habe ich gefragt, wie ich eine "ART" Rollback mit der TTable-Komponente machen kann, falls es das überhaupt geht.

Wenn Dein DBMS keine Transaktionen unterstützt, die - wie vorher schon erwähnt - über die TDatabase-Komponente ge-
steuert werden können, dann musst Du Dir halt selbst was einfallen lassen. Mit Deinem Wissen solltest Du das schaffen.

Gruß,

Alexander

@Sebo: Um ehrlich zu sein, ich wäre nie auf die Idee gekommen, das Du weißt was SQL bedeutet. Insbesondere, da Du bei Deiner letzten Frage hier im Forum (Exceptions auslösen), nicht mal in der Lage warst, das Wort 'exceptions' in der BCB-Hilfe einzugeben. Der zweite Eintrag dort lautet nämlich 'auslösen'. Ich wollte Dich nicht überfordern(!), deshalb die vereinfachende Antwort. Da auch Deine anderen Postings hier Anfängerfragen sind, bin ich davon ausgegangen, dass Du so gut wie nichts weißt... Mit Sicherheit weiß ich jetzt aber, dass Du ziemlich überheblich und unhöflich bist.

dschensky

Joe_M.,

Joe_M. schrieb:

Die Frage war wie man einen Rollback macht. Und da finde ich den Hinweis auf TDatabase und Transaktion nicht falsch?!?

hmm ... sagen wir, SeboStone hat sich da etwas schwammig ausgedrückt. Irgendwie schien mir, er wolle ein Table->Insert() mit nachfolgender Exception rückgängig machen. Dazu währe halt eine Table->Cancel() das übliche Mittel gewesen.

SeboStone

@Joe_M.:
Kann schon sein, dann bin ich hier ja genau richtig. Antworten wie "Guck doch in der Hilfe nach!" oder ein Link zu Google ist hier ja absolut normal. Und hinterher stellt sich raus, dass derjenige wirklich keine Ahnung hat, zumindest nicht von der gestellten Frage. Wie nennst Du das?
Und richtig, ich bin in BCB ein Neuling, ich programmiere eher mit VC++ und dort auch (fast) nur C für Microcontroller, Motorola-Prozessoren, Embedded Systems, etc. als Subunternehmer eines Subunternehmens für Thompson (MP3PRO) und Fraunhofer-Institut (MPEG4, MP3s) http://www.iis.fraunhofer.de/.
Ist schon richtig, hab' mir das "exception Ding" nicht angesehen, weil ich dachte dass es etwas kompliziert ist und dass es hier jemand gibt der es weiss und es so schneller geht. Ansonsten kannste mir gerne aus dem Weg gehen wenn ich Dich soooo anwider, da hab' ich kein Problem damit.

@dschensky:
Ha! Genau das hab' ich gesucht! Ich hab' die Hilfe nach was passendem durchforstet und hab's nicht gesehen! Hab' wohl eher an sowas wie "Table->Rollback()" gedacht! *lol* Keine Ahnung warum! Danke Dir!

Sebo