Autor |
Beitrag |
colaka
      
Beiträge: 200
Erhaltene Danke: 4
Win XP, W7
Delphi 2005 Prof.
|
Verfasst: Fr 29.03.13 22:51
Hallo,
nachdem ich mir jetzt doch endlich mal einen neuen Rechner mit Windows7 angeschafft habe und ein neues Projekt beginnen möchte, will ich jetzt wohl oder übel auch Abschied nehmen von meiner geliebten BDE.
Doch welches Tabellensystem soll ich nehmen?
Da ich vorläufig noch an Delphi7 und Delphi2005 festhalten möchte, sollte es bei diesen Delphiversionen installierbar sein. Falls möglich, sollte es aber auch unter den aktuellen Delphiversionen laufen. Wenn ich doch mal aufsteigen sollte, will ich nicht wieder auf dem Abstellgleis gelandet sein, und mir nicht wieder anhören müssen: "Was willst Du mit dem alten Schrott?".
Außerdem wäre es gut, wenn es deutsche Bücher oder Tutorials geben würde, weil ich kein Englisch verstehe.
Am liebsten wäre es mir, wenn es auf der Tool-Palette auch eine TDatasource-, eine TTable-Komponente usw. geben würde. Dann würde mir der Umstieg vielleicht nicht so schwer fallen.
Da ich nur Einzelplatzanwendungen schreibe, möchte ich nicht erst noch irgendwelche Datenbank-Server installieren müssen.
Was meint Ihr? Was wäre für mich geeignet?
Vielen Dank
_________________ Mit 2 Stunden Ausprobieren kann man sich oft 5 Minuten Nachdenken ersparen
|
|
mandras
      
Beiträge: 431
Erhaltene Danke: 107
Win 10
Delphi 6 Prof, Delphi 10.4 Prof
|
Verfasst: Fr 29.03.13 22:55
Für derartige Fälle ist u.a. Firebird eine gute Wahl. Für die Programmentwicklung empfiehlt es sich die Serversoftware auf dem Entwicklungsrechner zu installieren, für die damit erstellte Software gibt es dann noch einen sogenannten "Embedded Server" der aus ein paar wenigen Dateien besteht, die zusammen mit der EXE weitergegeben werden und keine extra Installation erfordern.
|
|
PC-John
Hält's aus hier
Beiträge: 15
|
Verfasst: Mi 17.04.13 23:44
Viel einfacher geht das Alles!
Nimm die Absolute-Database von www.componentace.com
Für private Nutzung ist Absolute-DB kostenlos.
Es kann auch ohne jegliche Probleme eine Multiuser-Anwendung daraus gemacht werden, eine entsprechend aufgebohrte KOmponente einsetzen genügt schon.
Hat volles SQL mit dabei, für "normalen" Zugriff und Abfrage muss kein bisheriger BDE-Code umgeschrieben werden, nur das ansprechen der Database muss angepasst werden.
Absolute-DB braucht keinen Server, hat keine DLL zum mitliefern, es ist ein einziges Database-Feile, und sonst nix zusätzliches. Der ganze Rest steckt in der Database-Komponente. Was willst Du mehr?
Grüsse von PC-John
|
|
bummi
      
Beiträge: 1248
Erhaltene Danke: 187
XP - Server 2008R2
D2 - Delphi XE
|
Verfasst: Do 18.04.13 00:13
Ich halte mich aus den Glaubenskriegen gerne heraus.
Rein persönlich verwende ich bei Netzwerkanwendungen am liebsten MS SQL-Server (die kostenlosen Expressversionen tun es meist ebenfalls).
Für Einzelplatzanwendungen bevorzuge ich trotz der kruden SQL-Syntax Access (nicht das Programm sondern nur die MDB's), da ich hier die Datenbanken direkt aus Delphi heraus erstellen kann, die Performance und der Funktionsumfang befriedigend ist und ich wie bei SQL-Server auf ADO setzen kann.
_________________ Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS
Für diesen Beitrag haben gedankt: FinnO
|
|
Perlsau
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Do 18.04.13 10:28
PC-John hat folgendes geschrieben : | Viel einfacher geht das Alles! Nimm die Absolute-Database von www.componentace.com Für private Nutzung ist Absolute-DB kostenlos. |
Was ist denn an Absolute einfacher als z.B. bei Firebird? Noch dazu ist Firebird auch bei kommerzieller Nutzung kostenlos, ein nicht zu unterschätzender Vorteil.
"An individual may use Absolute Database Personal in a project if he / she is the only user of this project." Heißt auf deutsch: Wenn ich damit Freeware entwickle, fallen Lizenzgebühren an. Wer will denn sowas?
PC-John hat folgendes geschrieben : | Es kann auch ohne jegliche Probleme eine Multiuser-Anwendung daraus gemacht werden, eine entsprechend aufgebohrte KOmponente einsetzen genügt schon. |
Und diese "aufgebohrte" Komponente kostet dann wieviel?
PC-John hat folgendes geschrieben : | Hat volles SQL mit dabei, für "normalen" Zugriff und Abfrage muss kein bisheriger BDE-Code umgeschrieben werden, nur das ansprechen der Database muss angepasst werden. |
Ist das beim Verwenden z.B. von Firebird etwa anders?
PC-John hat folgendes geschrieben : | Absolute-DB braucht keinen Server, hat keine DLL zum mitliefern, es ist ein einziges Database-Feile, und sonst nix zusätzliches. Der ganze Rest steckt in der Database-Komponente. Was willst Du mehr? |
Firebird Embeddet benötigt ebenfalls keinen Server. Egal ob Embedded- oder Serverversion: Firebird benötigt auch nur ein Database-File. Ich sehe bei Absolut eher eine Kostenfalle, in die ahnungslose User gelockt werden sollen, ähnlich wie bei MySQL, das zwar kostenlos, aber bei Verwendung von DB-Komponenten auf eine kostenpflichtige DLL angewiesen ist, und würde daher dringend davon abraten.
Ich hoffe nur, daß deine wiederholt dargestellte Lobpreisung von Absolute Database, die in meinen Augen stark übertrieben wirkt, nicht darauf basiert, daß du für diese Firma arbeitest oder Provisionen kassierst 
|
|
Lemmy
      
Beiträge: 792
Erhaltene Danke: 49
Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
|
Verfasst: Do 18.04.13 11:27
Perlsau hat folgendes geschrieben : |
PC-John hat folgendes geschrieben : | Hat volles SQL mit dabei, für "normalen" Zugriff und Abfrage muss kein bisheriger BDE-Code umgeschrieben werden, nur das ansprechen der Database muss angepasst werden. |
Ist das beim Verwenden z.B. von Firebird etwa anders? |
ja würde ich schon sagen. Denn TIB_TAble oder ein TIB_Query mit "Select * from" ist in einer umfangreicheren Produktivumgebung nicht sinnvoll und kann die Performance unter der von BDE drücken.
Dann noch das Transaktionsmanagement - wer sich damit nicht beschäftigen will, für den ist Firebird vielleicht wirklich nicht geeignet.
Rückblickend muss ich für mich sagen, dass ich die Entscheidung nie bereut habe, und ja ich habe mir zwischenzeitlich auch immer wieder Alternativen (Absolut, TurboDB,...) angeschaut und auch kleine Projekte gemacht - für mich sind die keine Alternative zu Firebird!
|
|
Perlsau
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Do 18.04.13 15:19
Lemmy hat folgendes geschrieben : | ja würde ich schon sagen. Denn TIB_TAble oder ein TIB_Query mit "Select * from" ist in einer umfangreicheren Produktivumgebung nicht sinnvoll und kann die Performance unter der von BDE drücken. |
Meine Frage bezog sich auch mehr auf das "ist volles SQL dabei" – als ob die anderen genannten Alternativen nur den halben SQL-Umfang böten.
Aber das mit dem TIB_Table hab ich jetzt nicht auf Anhieb verstanden. Von welchen DB-Komponenten schreibst du hier?
Lemmy hat folgendes geschrieben : | Dann noch das Transaktionsmanagement - wer sich damit nicht beschäftigen will, für den ist Firebird vielleicht wirklich nicht geeignet. |
Kommt wiederum auf die DB-Komponenten an. Mit IBDac ist alles mindestens so einfach wie mit Ado. Einzig die mitgelieferte DBGrid-Komponente TCRDBGrid zeigte ein paar Macken rund ums Sortieren via Titelklick. Devart hat mir aber bereits versichert, daß der Fehler im nächsten Release behoben sein wird. Mit Transactionsmanagement hab ich auch keine Probleme. Überhaupt zeigen diese Komponenten eine erfrischende Vielzahl angenehmer Zusatzoptionen wie z.B. das Property QueryRecCount bei TIBCTable, das dafür sorgt, immer die korrekte Datensatz-Anzahl geliefert zu bekommen, oder das Property FetchAll, das mir den gesamten Tabelleninhalt auf einmal abholt. Das verhält sich zu Ado oder Zeos wie ein Porsche zum Fahrrad ... für 99,- Euro ohne Quellcode (wer braucht den schon?) kann man da wirklich nicht meckern. Ach ja, natürlich kann man damit auch Interbase-DBs ansprechen ...
Lemmy hat folgendes geschrieben : | Rückblickend muss ich für mich sagen, dass ich die Entscheidung nie bereut habe, und ja ich habe mir zwischenzeitlich auch immer wieder Alternativen (Absolut, TurboDB,...) angeschaut und auch kleine Projekte gemacht - für mich sind die keine Alternative zu Firebird! |
Das kann ich vollumfänglich unterschreiben: Firebird ist die kostenlose Datenbank, die vielfach auch bei großen Datenbeständen und hoher Zugriffszahl eingesetzt wird, wie z.B. bei der deutschen Presseagentur dpa. Sie kann zwar nicht mit dem Funktionsumfang von Oracle, MsSQL und MySQL mithalten, aber das, was die bieten, benötigt man auch nur selten.
Ich lerne jeden Tag, an dem ich mich mit Firebird befasse, wieder was dazu. Vor einigen Monaten hab ich gelernt, wie man Views erstellt, um sich die lästige und zeitraubende Lookup-Felder im Programm zu ersparen. Ich kann mir neue Typen selber basteln oder via StoredProcedures etliche Operationen in die Datenbank verlegen. Firebird ist sehr gut dokumentiert, besonders wenn man das Buch von Helen Borrie zur Verfügung hat (gibt's inzwischen auch für neuere Firebird-Releases).
Firebird muß man nicht gründlich studieren, um damit sichere und anwenderfreundliche Datenbank-Anwendungen zu realisieren, und wenn man es dennoch tut, ist man damit viel schneller fertig als bei den drei zuvor genannten DBM-Systemen ...
|
|
Lemmy
      
Beiträge: 792
Erhaltene Danke: 49
Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
|
Verfasst: Do 18.04.13 21:06
hi,
Perlsau hat folgendes geschrieben : |
Meine Frage bezog sich auch mehr auf das "ist volles SQL dabei" – als ob die anderen genannten Alternativen nur den halben SQL-Umfang böten.
Aber das mit dem TIB_Table hab ich jetzt nicht auf Anhieb verstanden. Von welchen DB-Komponenten schreibst du hier? |
im Grunde von IBX, weil die meisten halt den Weg einschlagen und wie immer einfach drauf los programmieren. Und genau da geht halt das meiste schief und dann kommen Alternativen wie ADS usw. gerade recht... Und um das hier nochmal klar zu sagen: IBX ist NICHT kompatibel zu Firebird > 1.5 !
Perlsau hat folgendes geschrieben : |
Kommt wiederum auf die DB-Komponenten an. |
Das gilt nur für Einzelplatzanwendungen oder kleinen Netzwerkprogrammen - wenn du aber mal 10, 20 gleichzeitige Anwender hast, die vergleichbare Eingaben und Änderungen machen, musst Du dir zum Thema Deadlock usw. schon Gedanken machen, sonst knallt dir die Anwendung beim Kunden gegen die Wand.
Aber dazu gibt es ja entsprechende Dokumentation die man halt auch mal lesen muss
Grüße
|
|
WasWeißDennIch
      
Beiträge: 653
Erhaltene Danke: 160
|
Verfasst: Do 18.04.13 21:09
Ich kann mir nicht vorstellen, wie die Transaktionsproblematik bei Multiuser-Zugriff vom DBMS abhängen soll, die hat man doch überall. Und dass "SELECT *" nicht zum guten Ton gehört, sollte sich auch mittlerweile herumgesprochen haben.
|
|
Lemmy
      
Beiträge: 792
Erhaltene Danke: 49
Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
|
Verfasst: Do 18.04.13 22:12
WasWeißDennIch hat folgendes geschrieben : | Ich kann mir nicht vorstellen, wie die Transaktionsproblematik bei Multiuser-Zugriff vom DBMS abhängen soll, die hat man doch überall. Und dass "SELECT *" nicht zum guten Ton gehört, sollte sich auch mittlerweile herumgesprochen haben. |
und wenn das DBMS schlicht keine Transaktionen hat? Wie soll es da zu Problemen kommen? und wenn ich mich recht erinnere unterstützt Paradox keine Transaktionen  Wie soll dann also Wissen da sein, wie man mit Transaktionen arbeitet?
Und Select * und so sollte sich rumgesprochen haben? Warum tauchen dann immer noch an jeder Ecke solche Software auf? Warum tauchen hier immer wieder Typen auf die Probleme mit IBX und Firebird haben? WEnn RTFM wirklich funktionieren würde, dann wäre hier und in den anderen Foren deutlich weniger los....
Aber wir kommen immmer weiter vom eigentlichen Thema ab...
|
|
|