DB aus Dialog heraus auslesen
-
Cneueklasse klingt so, als wenn er eine neue Klasse erstellen soll.
Dabei muss er das doch gar nicht, sondern kann einfach die Klasse nehmen, die er für m_pBGSet genommen hat.
Ansonsten stimme ich dir zu soweit ich folgen konnte.
-
dokdok: ich weiss nicht so ganz was du gemeint hast aber ich weiss inzwischen wo mein Fehler lag:
Ich hab eine Datenbank mit 2 Tabellen und hab angenommen das CRecordset damit zurecht kommt wenn ich beide Tabellen benutz...So wie es mir grad vorkommt multipliziert es die Tabellen
Tabelle A | Tabelle B | Angezeigt 10 Einträge|0 Einträge| 0 10 Einträge|1 Einträge| 10 10 Einträge|2 Einträge| 20 ... | ... | ...EDIT: ok hab auch grad gesehn das ein CRecordset zu behandeln ist wie eine SELECT anfrage *grml*
-
Taelan schrieb:
So wie es mir grad vorkommt multipliziert es die Tabellen
Das ist normal, wenn du keine Beziehung zwischen den Tabellen hast.
Recordsets für mehr als eine Tabelle sind im Prinzip Views. Und außerdem ReadOnly.
-
Das es Readonly ist stört mich nicht, ich benutz es auch nur um die Daten anzuzeigen.
-
ich würde so machen. eine klass für eine tabelle..
so wird es auch übersichtlicher.man kann sich vorstellen mehrere tabellen da sind.
@ estartu_de
wie kann mann die Beziehung zwischen 2 tbl berücksichtigen.
ich versichte immer darauf
-
dokdok schrieb:
@ estartu_de
wie kann mann die Beziehung zwischen 2 tbl berücksichtigen.
ich versichte immer daraufDie musst du im DBMS festlegen, also zum Beispiel direkt in Access.
Ich glaube, man kann die auch in der Recordsetklasse festlegen, aber da weiß ich gerade nicht wie.Ich mache das aber auch so wie du: Pro Tabelle ein Recordset und Zusammenhänge werden im Programm ausgewertet.
Anders wäre das ziemlich kompliziert mit Recordsets, das habe ich lieber gelassen.
-
Prinzipiell muss man in der DB keine Beziehungen zwischen den Tabellen definieren (ist zwar ein schlechtes Design aber es geht).
Wenn Du eine gemeinsame View aus zwei Tabellen haben willst, brauchst DU natürlich zwischen den Tabellen zumindest logisch eine Bezieheung. Diese musst Du dann nur noch in ein passenden SQL-Statement umwandeln (mittel SELECT und JOIN-syntax).
Siehe:
http://www.sql-und-xml.de/sql-tutorial/tabellen-verknuepfen-mit-join.html
http://www.aspheute.com/artikel/20001023.htm
Eine Beziehung in der Datenbank musst Du prinzipiell nur dann anlegen, wenn die Datenbank selber irgendwelche überprüfungen (z.B: ob der Fremdschlüssel existiert) oder aktioenen (z.B. delete-cascade) ausführen soll.
-
Du hast recht . ich versichte auf Beziehungen und schlüssel um einfacher zu sein und mache wie estartu_de und lasse das Programm selber rumschaffelen in der Tabellen.
jochen klambach schrieb:
Wenn Du eine gemeinsame View aus zwei Tabellen haben willst, brauchst DU natürlich zwischen den Tabellen zumindest logisch eine Bezieheung. Diese musst Du dann nur noch in ein passenden SQL-Statement umwandeln (mittel SELECT und JOIN-syntax).na klar die Beziehungen unter sql kenne ich gut. aber leider ich arbeite gern mit ODBC und nicht mit ADO. und mit ODBc kann ich select oder sql statments nicht verwenden ausser filtr und sort.
ADO habe mal getestet von (C++ in 21 tage)Buch und ziemlich hat Fehler wie immer im Beispiel und könnte nicht komplieren. dann hatte ich kein pock mehr.
-
Ich hab das jetzt auch so gemacht, wobei ich nicht sonderlich zufrieden damit bin, meine DB Proffesorin würd vermutlich nen Herzschlag kriegen
-
Datenbank und Gui sind zwei Welten - wobei ich CRecordsets zur Gui zähle.
Wenn man dynmamische Recordsets nimmt (aus deren Nutzung ich noch nicht schlau geworden bin), dann kann man es deiner Professorin ziemlich recht machen.
Im Wesentlichen muss man sich entscheiden:
1.) Ist das DBMS ein Ablagesystem mit begrenzter Intelligenz?
(Hier mal ein Trigger, dort mal ein View?)
2.) Oder ist die GUI ein dummes Anzeigemittel und die Datenbank erledigt alles was mit der Datenhaltung und Modofikation zu tun hat?Alle Zwischenlösungen werden mit der Zeit ziemlich schwer zu pflegen.
