Moin...
Auf die Gefahr hin, mir wieder den Mund zu verbrennen...
Zitat:
Ein Memo für die Eingabe von
SQL, eine Abfragekomponente, um eben diese auszuführen.
SQL im Klartext einzugeben ist keine gute Idee. Erst Recht für den User. Siehe
SQL Injection.
Ich schrieb für mich und nicht für den User!!!
Außerdem handelt es sich dabei dann nicht um
SQL Injection, sondern um fehlerhafte oder falsche oder ungeeignete oder systemzerstörenden SQLs. Aber nicht um "hinterherum" manipulierte Abfragen.
SQL-Injection ist: Wenn ich ein vorhandenes
SQL, auf das ich direkt keinen Einfluss habe, durch Parametermanipulation und/oder Ausnutzung von Softwareschwachstellen, ein
SQL mache, dass der eigentlichen Nutzung zuwiderspricht. Die Eingabe eines
SQL-Statments zwecks Ausführung, ist kein
SQL-Injection.
Ansonsten wäre ja jedes
SQL, das ich in FlameRobin bei "Execute
SQL Statement" eingebe, eine
SQL-Injection, dito. bei der Nutzung von TOAD für Oracle ...
Zitat:
Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge.
...lasse ich mit Ach und Krach durchgehen.
Auch hier: Für mich, für die Entwicklung und nicht für den User!!!
Zitat:
Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert )
Überspitzt ist kein Ausdruck...
Wie kommst du denn darauf? Es gibt haufenweise Techniken die auch die datensensitiven Controls überflüssig machen. Denn die machen dir die Optik der Oberfläche zur Sa..., weil diese nicht als
DB Version vorliegen.
Ob und wie ich die Daten anzeige, steht auf 'nem anderen Blatt, dass ist (auch mit datenbansensitiven Komponenten) datenbankunabhängig. Kein Control greift selbständig direkt auf die Datenbank zu.
Zitat:
Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.
Zitat:
if you don't have a host name, because yours is a local or embedded Firebird server
...
Zitat:
Klar: Bei SQLite kommt die
DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.
3 DDL´s...Der Vorteil ist, das man bei Firebird mit der
gleichen Datenbank sowohl Embedded als auch mit dem Server Multi User arbeiten kann.
Zitat:
Da beim TE
Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an.
Um Gottes Willen.
Wer behauptet
Access sei eine Datenbank sagt auch jeden Tag "Jehowa" und bettelt darum gesteinigt zu werden.
Nochmal: Zum professionellen Einsatz nicht geeignet. Wer Office hat und dort
Access nutzt, hat damit nunmal eine Datenbank. Ob die nun jedem Profi gefällt, steht doch auf 'nem anderen Blatt.
Zitat:
Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt".
...so soll es sein.
Zitat:
Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch.
Bei
SQL ist der Standard (
SQL-92) das Non plus Ultra! Da weicht
Access schon mal ab.
Wenn ich eine
Access.mdb nutze
ohne die MS-Oberfläche zu nutzen, kann ich mich an das
Non plus Ultra! halten, ohne Probleme!!!
Zitat:
wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.
Das ist mit
Access in naher Zukunft zu erwarten, weil die Anforderungen meistens über die erste Vorstellung hinausgehen.
Sagen wir mal so: Solange ich
Access kenne, wird es bald nicht mehr existieren. So seit 20 Jahren?
Die
BDE war auch mal "die Datenbankschnittstelle" für Delphi und ist längst Schnee von gestern. Auch DBase war mal "das" relationale Datenbanksystem für PC. Kennt das noch wer? Nein, Schnee von gestern. Das Problem habe ich letztlich mit allem in der EDV.
Wird es Delphi "immer" geben? Keine Ahnung, hoffen wir es.
Letztendlich entscheidet der Umfang der Anwendung über das
DBMS. Im Moment sind es 16 User...
Zitat:
darüber können dann die maximal 16 Benutzer zugreifen
...das sieht nach einem Mehrbenutzersystem aus. Da scheidet
Access schon mal aus.
Zitat:
und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen
Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift?
Es ist kein Mehrbenutzersystem: Der TE schrieb klar und deutlich:
Ein Gerät, ein Tablet. Da geht Mehrbenutzersystem nicht! Alle User benutzen das gleiche Gerät, dadurch habe ich zwar mehrere Benutzer aber noch lange kein Mehrbenutzersystem (zumindest hab' ich bisher darunter was anderes verstanden
)
Und
Access kann Mehrbenutzer, habe das (wenn auch sehr ungern, eben aus Deinen Gründen) trotzdem für ein paar Kunden meines Arbeitgebers so umsetzen müssen. Und es lief: problemlos und wartungsfrei! (Und auf so 'ne Idee wäre ich freiwillig nie von alleine gekommen!)
Und nochmal nein: Für den professionellen Einsatz nicht geeignet!!!
Und langsam gehen wir vom Thema ab: Es wird eine Grundsatzdiskussion, die einem Anfänger nicht wirklich bei der Entscheidungsfindung hilft. Man kann
Access nutzen, muss es aber nicht, es ist eine möglich Option, die man meiner Meinung nach unter Umständen in Betracht ziehen könnte. Diese Ansicht muss man nicht teilen.
Dem TE bleibt es überlassen für sich zu entscheiden, ob diese Möglichkeit für ihn in Betracht kommen könnte oder ob die Argumente dagegen seiner Sicht nach überwiegen. Dann muss er sich für was anderes entscheiden.
Nach dem letzten Beitrag des TE scheint mir hier
Access eine durchaus sinnvolle Einstiegsmöglichkeit in die Datenbankprogrammierung. Es ist alles, für die Nutzung der Datenbank und die Entwicklung einer eigenen Software benötigte, vorhanden. Es muss nichts installiert werden, kein Lernaufwand für weitere Software, Oberflächen, Datenbankkonfiguration ...
Hätte ich mit so wenig Aufwand meine ersten Schritte bei der Datenbankentwicklung mit Delphi machen können, wäre ich erstmal zufrieden gewesen.
Bleibe bei der Meinung (trotz aller berechtigter Kritik): Für den Einstieg reicht das aus.
Und wenn es
Access irgendwann nicht mehr gibt, ist es auch nicht mehr Teil von MS-Office. Ja: Dann muss man sich Gedanken über ein neues oder anderes Datenbanksystem machen. Wer garantiert uns, dass es dann FireBird, SQLite ... noch gibt?