Datenbankanbindung
-
frag mal in einem geeigneteren forum (oder lass dich verschieben)
ich vermute, du arbeitest mit dem visual studio, ev. machst du mfc, da wäre eine db anbindung ja einfach (im mfc forum fragen).
oder du machst winapi, dafür gibt es hier ebenso eine geeignete unterkateogorie.
(->was ich damit sagen will: grenz mal compiler und bibliotheken ein, damit du richtig verschoben wirst... windows ist ja klar ).c++ standard kennt keine datenbanken.
-
Danke für deine Hilfe.
Ich benutze Viusial Studio 6. MFC brauche ich nicht.
Jedoch konnte ich auch dort kein Beispiel finden .
Bis jetzt ist mir auch noch nicht ganz klar was ich am besten dafür nehmen soll. Fände es tool wenn ihr eure Erfahrungen mit einbringen könntet.
( Für ein Code-Beispiel wäre ich unendlich dankbar )
-
hier
http://www.c-plusplus.net/forum/viewtopic.php?t=65271&highlight=access&sid=c2a9290c9b19e5765779afde66681fd0
der obere wäre ein beispiel fürs ansprechen der access db ohne mfc.es gibt massen beispiele, nutze mal die suchfunktion (schlagwort access oder odbc)
ich glaube, daß hier
http://www.programmersheaven.com/zone15/cat238/2438.htm
waren noch beispiele, wie ansprechen und auslesen... schau mal nach.erstmal soweit und auch in die msdn schauen.
-
-
Warum nutzt du nicht SQLite? Die DB wäre perfekt für deine Ansprüche und ist
wesentlich leichter zu handhaben als eine Access-Datenbank. Unabhängig davon,
dass ich von Access sowieso die Finger lassen würde - in meinen Augen ist
Access einfach nur großer Schrott
-
EnERgYzEr schrieb:
Warum nutzt du nicht SQLite? Die DB wäre perfekt für deine Ansprüche und ist
wesentlich leichter zu handhaben als eine Access-Datenbank. Unabhängig davon,
dass ich von Access sowieso die Finger lassen würde - in meinen Augen ist
Access einfach nur großer Schrottda stimmen ich zu. nur manchmal muss man es machen wegen der auftraggeber.. wenn die sich nicht an eine neue db rantraun... thats life.
-
Hi EnERgYzEr,
woher weisst du das Access Schrott ist. Hörensagen oder eigene Erfahrung. In wievielen deiner Projekte hattest du denn Probleme. Meiner Erfahrung nach ist für Standalone-Datenhaltung eine FileSharing-Datenbank in jedem Fall vorzuziehen. Das muss nicht Access sein, ist aber meistens die einfachste Lösung weil die meisten Kunden nun mal MS-Office einsetzen.
Alle notwendigen Treiber ODBC/ADO sind daher ebenfalls schon vorhanden und es muss nichts zusätzlich installiert werden. Und Admin-Tools die mit MDB-Dateien umgehen können, wenn keine Access-Vollinstallation vorhanden ist, gibts im Dutzend und umsonst im Netz.
Solange man mich nicht mit vorgehaltener Pistole zwingt werde ich bei keinem Kunden SQL-Server, DB2, oder Oracle einsetzen der nicht mindestens über ne eigene IT-Abteilung mit DBA verfügt
-
Erfahrungen: http://www.dbcopy.de/
Das DAO Interface kann man ja nicht mehr verwenden, da es sowieso komplett
veraltet ist. ADO ist pur viel zu umständlich - also bleiben nur noch
Bibliotheken. Dann brauchen die Kunden immer die aktuellsten Treiber, um
auf die Datenbanken zugreifen zu können.Auch ist die Performance für jeden auch nur semi-professionellen Anspruch
viel zu niedrig. Über den SQL-Support von Access brauchen wir ja nicht reden,
oder?Daraus hab ich für mich die Konsequenz gezogen: Für Desktop-Lösungen: SQLite,
dass eine brauchbare Performance hat, einfach anzusprechen ist und gute
SQL-Unterstützung hat. Bei Servern habe ich bis jetzt erst mit mySQL tiefere
Erfahrungen sammeln können - Mit Oracle werde ich mich erst demnächst
beschäftigen.
-
Ein Produkt-Link als Erfahrungsbericht, entgeht mir da was. ?
Neben DAO geht ebenso RDO oder ADO. Was ist an der Verwendung von normalen SQL-Statements (RDO/ADO) problematisch. In Verwendung als Datenbasis einer Standalone-Anwendung sehe ich auch keine Probleme mit dem SQL-Standard. Locking-Mechanismen und/oder paralle Datenverarbeitung oder gar Transaktionen spielen in diesem Fall ja wohl keine Rolle. Die Einfach einer "Datensicherung", nämlich speichern der MDB-Datei, spielt aber beim konkreten Einsatz durchaus eine Rolle. Schon mal nen Kundenanruf wegen Datenbankproblemen bekommen, wenn der Kunden nicht weiss wo und von wann, falls überhaupt eine Sicherung vorhanden ist. Und wenn du erstmal mit der Sekretärin des "IT-Abteilungsleiter", selbst leider in Urlaub, einen Restore einer Oracle-Datenbank versucht hast, dann wünscht du dir (jede) FileSharing-Datenbank zurück.
-
Die Software wurde von meiner Firma entwicklet, deshalb der Link zum Thema
Erfahrungen.Zu Access: Ich sehe SQLite als brauchbare Alternative zu Access - auch hier
hast du nur eine Datei, die man beliebig kopieren / verschieben, etc. kann.
Das Problem ist nur, dass es nicht so ein "schönes" Interface dazu gibt. Aber
im Regelfall werden hier ja eh spezielle Interfaces für ein Unternehmen
entwickelt, so dass man hier wieder ein Argument für SQLite hätte.Zur SQL-Unterstützung von Access: Ich glaube mehr als SELECT/UPDATE/DELETE
ist nicht drin, oder? Und wenn ich die Syntax für ein Datums-Feld sehe,
bekomm ich jedesmal wieder einen Lach-Heul-Krampf
-
Danke für die vielen Tipps. Ich denke mir nur, dass ich für ein sSpiel keine Multiuserdatenbank benötige oder? Ich sehe Access fast als einfachste Lösung. Oder liege ich da falsch?! Schon nur, das nicht weiter Komponenten für das Spiel inst. Werden müssen.
Werde Morgen gleich mal die super Beispiele ausprobieren. Danke euch erstmals für den tollen Einstieg, den ihr mir ermöglicht habt.Noch etwas zu eurer allgemein Meinung zu Access (aus Datebanksicht ohne Bezug zu C++). Ich finde Access gar nicht so schlecht, wenn man sich das ganze mal etwas tiefer anschaut ist doch recht viel erreichbar. Für kleinere Zwecke ist es doch recht brauchbar (Gui etc. ist ja alles schon vorhanden). Jedoch würde ich Access mit keinem anderem Datenbanksystem vergleichen, denn Access ist und bleibt eine Singeluserdatenbanksystem.
-
-
Dann ist es ja auch ne FileSharing-Datenbank wie Access. Den Vorteil den ich bei Access halt häufig erlebt habe, ist gerade die Anbindungsmöglichkeit durch ADO. Das heisst, dadurch kannst mit jeder COM-fähige Programmiersprache in (fast ;)) gleicher Art Weise mit allen (ADO-)Datenbanken arbeiten. Ob SQLite das auch kann weiss ich nicht !??
-
Nein, SQLite hat nur eine C/C++ Api. Ist dafür halt unter allen Betriebs-
systemen einsetzbar und Open Source.Allerdings gibt es für so ziemlich jede Sprache einen entsprechenden Wrapper.
Darunter sind auch COM Wrappers oder auch z.b. Schnittstellen für Java:http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers
Auch ist SQLite mitleerweile in Version 3 verfügbar, die wohl als absolut
stabil gelten darf. Von der Performance haben wir in Tests sehr gute Ergebnisse
erzielt, die weit über Access hinausgehen. Die Ergebnisse beim Vergleich zu
mySQL hab ich leider nicht mehr im Kopf.Wers braucht, findet auch eine fast komplette Unterstützung des SQL-Standards.
-
Gibts zu SQLite eigentlich auch ein (kostenloses :)) Admin-Tool mit GUI damit zumindest auch mittelschwere DAU's ne Datenbank, Tabellen + Indizes anlegen können.
-
sqlite3::connection con("test.db"); int count=con.executeint32("select count(*) from sqlite_master where name='t_test';");
Sieht ziemlich einfach aus um auf die DB zuzugreifen. Wenn ich mir da die anderen Beispiele ansehe scheint dies wirklich ziemlich komfortabel zu sein.
Jedoch glaube ich nicht, dass dies die geeignete Lösung für (zurzeit noch) ein Singeluserspiel ist.Jedoch möchte ich hier die Diskussion nicht weiterführen welches Datenbanksystem besser ist, denn Access kann man (aus Datenbanksicht) nicht damit Vergleichen. Zudem möchte ich nicht vom Ziel dieses Beitrags abweichen und in eine völlig andere Richtung abschweifen...
-
Hier eine Übersichtsseite:
http://www.sqlite.org/cvstrac/wiki?p=SqliteTools
Das Tool scheint ganz vielversprechend zu sein:
http://sqlitebrowser.sourceforge.net/index.html (habs aber noch nicht getestet)
Und sonst: Ich entwickel in meiner Firma gerade ein Tool, dass wohl die dort
angebotenen weit übertreffen wird - aber das dauert noch
-
Für die letzten Zweifler hier eine Performance-Übersicht. Zum Vergleichen die
nosync Werte ansehen, da bei SQLite 3 dieses standardmäßig aktiviert ist.http://www.sqlite.org/speed.html
Also warum SQLite nicht auch für ein Spiel einsetzen? Die Performace von
Access wirst du wohl um ein vielfaches übertreffen. Auch ist es einfacher
ansprechbar und du wirst im Gegensatz zu Access keine Kompatibiliätsprobleme
haben. Solltest du mal auf Linux portieren wollen, brauchst du bei SQLite nur
neu kompilieren.@pint: Wieso kann man Access und SQLite nicht miteinander vergleichen? Beides
sind File Sharing-Datenbanken. Access-Datenbanken sind halt eng verbunden mit
dem Interface von Microsoft, aber auf das kann ich auch gerne verzichten.
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ja aber wenn die Firma mit MS Office arbeitet ist und bleibt Access für kleinere Dinge einfach die schnellste Lösung. Mit einem minimalen Datenbankwissen ist hier auch für ungeübte User einiges möglich. Leider kannst du in grösseren Firmen meist einfach auch nicht anders, da halt MS Access verlangt ist (punkt)
Versteh mich nicht falsch ich bin nicht der Access Befürworter jedoch ist in manchen Fällen Access die einfachste und schnellste Lösung. So genug geredet. Zurück zum eigentlichen Thema...
Werde mir das natürlich auch ansehen. Schlussendlich werde ich wohl die Lösung nehmen, welche ich am schnellsten zum laufen bringe. Hoffe ich komme noch bis vor dem Wochenende dazu. Werde aber euch informieren mit was ich es nun realisiert habe. Bin aber sehr positiv gegenüber Sqlite eingestellt, würde sagen du hast gute Überzeugungsarbeit geleistet (ein Gui wird ja für die Datenbank sowieso nicht benötigt, da dies indirekt das spiel selbst ist )
(Wenn du gerade ein super Beispiel zu sqlite rum liegen hast, post das Ding doch mal.)Ps.: Die ganze Community hier ist echt der Hammer, werde wohl bis auf weiteres in diesem Forum verweilen