Kauf- und Kontenverwaltung - Datenbank notwendig?

[HolgerX]

Hmm..

Zitat von jobo:

Access für Geld und relativ nicht Standard, will man nicht ohne konkrete Indikatoren.
Ebenso andere Systeme "für Geld" oder scheinbar kostenlos.

Access.. Und Geld.. ?
Wieso?
Alles für die Erstellung/Benutzung einer Access-Datenbank ist auf einem blanken Windows-Rechner schon vorhanden.
Ein Office mit der 'Oberfläche' Access wird nicht benötigt.

Per Delphi kann ich eine neue Access-DB anlegen, Tabellen erzeugen und damit arbeiten....

Vielleicht nicht mehr Stand der Technik, bzw von Microsoft ungeliebt, kann ich es jedoch auf jedem Windowssystem (so ab W2k SP4) ohne Installation verwenden..

Oder habe ich da was verpasst?

[Delphi.Narium]

Benutze häufig Access-Datenbank, aber nie die gleichnamige Software von MS.

Funktioniert, man braucht keinen Server, keine DLLs ...

Wenn die entsprechende Datenbankdatei in 'nem freigegebenen Verzeichnis liegt, ist sogar (ohne irgendwelche Zusätze) ein Mehrbenutzerbetrieb möglich. Klar, nicht unbedingt für tausende Nutzer aber so ein halbes Dutzend geht schon

Datenbankerstellen geht auch über die ODBC-Verwaltung. (weiß nicht ab welchem Windows und ggfls. bis zu welchem.)

Passende Gebrauchsanweisung findet man mit den Suchbegriffen odbc access db erstellen.

Und wenn man nur einmal eine Datenbankdatei braucht, kann man die so erstellen und muss das nicht extra programmieren.

Da hier aber nur eine Software mit einer Datenbank auf einem Rechner gewünscht ist, der von mehreren Benutzern (nicht zeitgleich) genutzt wird, reicht das vollkommen aus und ist auch für Datenbankunerfahrene recht einfach und leicht erlern- und händlebar.

[p80286]

Da kann ich nur unbedingt von abraten. Wenn es bisher funktioniert hat, dann hast Du Glück gehabt. Und ob Du ODBC oder eine andere Schnittstelle nutzt, eine DLL oder EXE ist immer im Spiel. Es kann sein, daß Du nichts explizit dazu laden mußt, aber ohne geht es nicht. Du brauchst immer eine Schnittstellensoftware und sei sie selbst geschrieben!

Gruß
K-H

[jobo]

@HolgerX,@Delphi.Narium
Ja, habt Ihr recht, früher hab ich das auch mal für Bastelprojekte gemacht. Je nach Installationsstand des Rechners mit/ohne Office dann noch mdac Module nachinstallieren, da gabs sogar extra von MS so ein Prüftool comchecker oder so, das einem dann hoffentlich erzählt hat, was wo noch fehlt. Heute vielleicht irgendwelche anderen Redistributables oder so, da bin ich nicht mehr auf dem Stand, ich denke das meinte auch p80286.
Ob der TE sich das als Anfänger antuen will/sollte, ist eine andere Frage. Erzeugung der Tabellen ist ja dann auch "Handarbeit" (oder man landet dann doch bei einem gefkauften Access für den Entwickler, was ohne Frage halbwegs Komfort für Tabellen und Abfragen stiften würde)
Also, streng genommen ist meine Aussage mit dem Geld falsch.
Aber das Geld würde ich dann doch eher in die oft bejammerte und ach so teure Delphi Version oder extra Datenbankkomponenten stecken, statt in Access.
Was an einem nackten Access Datenfile dann leicht und einfach ist, weiß ich nicht. Es ist von mir bekannten SQL Systemen am weitesten non konform zu SQL Standards, besonders wenn man im SQL noch irgendwelche Jet Funktionen einsetzt.

[Delphi.Narium]

Die Schnittstellensoftware ist hier Teil des Betriebssystem. Sie ist genauso sicher oder unsicher, wie z. B. alle Aufrufe der Windows-API. Es hat bisher funktioniert, aber muss es nicht für immer und alle Zeiten.

Deshalb kann man ja z. B. aktuelle Delphis nicht mehr auf älteren Windosen installieren.

Das Problem habe ich immer. Niemand kann mir garantieren, dass ich mit einem aktuellen FireBird (embedded) für immer und alle Zeiten eine heute geschriebene Software auf allen weiteren Windosen, die es noch so geben wird, nutzen kann. Dergleichen gilt auch für SQLite oder eine Delphiexe, die mit den heute aktuellen Datenbankkomponenten für den Zugriff auf z. B. Oracle geschrieben wurde.

Das beschriebene Problem

Zitat von p80286:

Und ob Du ODBC oder eine andere Schnittstelle nutzt, eine DLL oder EXE ist immer im Spiel. Es kann sein, daß Du nichts explizit dazu laden mußt, aber ohne geht es nicht. Du brauchst immer eine Schnittstellensoftware und sei sie selbst geschrieben!

habe ich immer. Ich brauche immer irgendwas, was zwischen meiner Applikation und der Datenbank "hängt". Egal ob ich jetzt eine DLL mitliefere (z. B. SQLite) oder mehrere (z. B. Embedded FireBird) oder über ADO auf Access zugreife oder sonstwie auf welche Datenbank auch immer.

Immer laufe ich Gefahr, dass früher oder später Änderungen an der Schnittstelle und/oder am Betriebssystem eine weitere Nutzung meiner Software verhindern.

Unabhängig von der Schnittstelle: Ich weiß nicht, ob eine heute erstellte Exe mit aktuellem Delphi und aktuellem Windows, in Zukunft weiterhin auf neuer Hardware und/oder neuem Windows funktionieren wird. Es ist eher davon auszugehen, dass dem nicht so sein wird.

Bei (übertrieben) konsequenter Beachtung des oben zitieren Einwandes, wäre von der Nutzung einer Datenbank abzuraten. Es besteht immer potentiell die Möglichkeit, dass es irgendwann nicht mehr funktioniert, weil Änderungen am Betriebssystem und/oder der genutzten Datenbankschnittstelle eine weitere Funktion verhindern. Letztlich sollte man dann auch keine eigene Software erstellen, da auch hier nicht sichergestellt werden kann, dass sie für alle Zeiten auf neuen Rechnern und neuen Betriebssystemversionen funktionieren wird.
Selbst bei der Nutzung von Fremdsoftware hat man keine Garantie, dass man diese immer und für alle Zeiten nutzen kann.

Einen Tod muss man sterben.

Und wenn man gut programmiert, dann baut man sich in die Datenbankanwendung eine Exportfunktion für die Daten ein und ebenso eine Importfunktion. Damit kann man dann schonmal für Datensicherungen ausserhalb der Datenbank sorgen. Dies halte man bitteschön SQL-Standardkonform.

Sollte es die Unterstützung der genutzten Datenbank nicht mehr geben, ändert man das Programm auf die Nutzung einer anderen Datenbank, was mit den aktuellen Datenbankkomponenten kein wirkliches Problem sein sollte, nimmt den letzten Datenexport und importiert ihn in eine neue, andere Datenbank (beliebiger Hersteller) und kann die Software weiter nutzen.

@Jobo:

Egal welche Datenbank: Halte mich an den SQL-Standard, dann sind exotische Sonderlocken diverser Datenbanksystem nicht von belang.

Tabelle erstellen kann man halt mit reinem SQL. Wenn ich FireBird (embedded) oder SQLite nutze, hab' ich ja auch nicht sofort irgendeine komfortable Oberfläche. Für mich ist Access nichts weiter als eine Schnittstelle zu einer Datenbankdatei. Bisher ist sie bei Windows meist dabei. Bei SQLite und FireBird muss ich mich halt selbst drum kümmern.
Rein aus Programmquelltextsicht besteht für mich da kein Unterschied. Man nehmen (z. B. die Zeos-Komponenten oder was man immer auch nutzen möchte), sage der, welche Datenbank sie zu gefälligst zu nehmen habe und gut ist.

So wie Access SQL-technische Besonderheiten hat, haben es FireBird und SQLite auch. MS-Server und Oracle sind auch nicht vollumfänglich kompatibel, noch MySQL und Postgres (und was weiß der Geier noch) dazu und irgendwie passt nix mehr so ohne weiteres zusammen.

Fazit: Egal, was man hier jetzt empfiehlt: Für jeden Lösungsvorschlag finden sich sehr schnell eine Reihe fundierter und berechtigter Gegenargumente.

Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!) und für den Anfänger zur Erstellung der ersten Datenbankanwendung erstmal vollkommen ausreichend. Einmal Datenbankdatei erstellen und dann mit Delphi das Programmieren einer einfachen Datenbankanwendung lernen. Wenn man dass dann kann und sich irgendwann mit Datenbanken auskennt, sollte ein Umstieg auf eine beliebige "professionelle" Datenbank dann kein Problem sein.

Für eine Unternehmenssoftware jedoch sicherlich eher induskutabel.

[jobo]

Zitat von Delphi.Narium:

Die Schnittstellensoftware ist hier Teil des Betriebssystem.
..snip..
Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!)
..

Widerspricht sich das nicht?

Treiber hin oder her, ich müsste auch für andere Systeme Treiber installieren (außer meine Delphikomponenten machen das nativ).
Access halte ich aus diversen Gründen für "exotisch" und nicht naheliegend, weder für Anfänger noch Fortgeschrittene. Naheliegendere Systeme sind nur ein paar Klicks entfernt.

[Delphi.Narium]

Zitat von jobo:

Zitat von Delphi.Narium:

Die Schnittstellensoftware ist hier Teil des Betriebssystem.
..snip..
Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!)
..

Widerspricht sich das nicht?

Treiber hin oder her, ich müsste auch für andere Systeme Treiber installieren (außer meine Delphikomponenten machen das nativ).
Access halte ich aus diversen Gründen für "exotisch" und nicht naheliegend, weder für Anfänger noch Fortgeschrittene. Naheliegendere Systeme sind nur ein paar Klicks entfernt.

Ja, der Widerspruch ist vorhanden, aber man kann leicht prüfen, ob's nun funktionieren wird oder nicht.

Access ist exotisch, wenn man es aus der Sicht der gleichnamigen Software von MS sieht. Die ist meiner Meinung nach ein Graus.

Nimmt man nur "normales" SQL, dass auch gegen jede andere Datenbank läuft, dann ist die Datenbankdatei einfach nur 'ne Datenbankdatei. Man merkt aus dem Programm heraus (egal ob als Anwendern oder Entwickler) nicht, dass da ein (wie Du sagst) Exot hinter hängt.

Welches sind bitte die "Naheliegenderen Systeme, die nur ein paar Klicks entfernt sind?"

Was muss der Laie tuen, um eine funktionierende Datenbankanwendung schreiben zu können?

Wo muss z. B. bei SQLite die DLL hin?
Wie sieht es bei embedded FireBird aus?

Kann man deren Schnittstellen ggfls. auch zeitgleich für mehrere Programme, aber unterschiedliche Datenbanken nutzen?

Kann eine Datenbank von mehreren Programmen zeitgleich genutzt werden?

Und mir ist klar: Für professionelle Software ist mein Vorschlag absoulut ungeeignet.

[Bernhard Geyer]

Zitat von HolgerX:

Alles für die Erstellung/Benutzung einer Access-Datenbank ist auf einem blanken Windows-Rechner schon vorhanden.
...
Oder habe ich da was verpasst?

Jo, hast du.
MS ist zwar auf "normalen" Windows-Systemen vorhanden, aber nicht immer.
Im Berech Embededd ist die Jet-Engine ein Optionaler Teil den man (um Platz zu sparen) auch abwählen kann.
MS hat (früher) die Jet-Engine auch im Rahmen der MDAC-Installation verteilt. Die letzten Versionen waren aber ohne dieser bereit gestellt.

Ich vermute das MS die Jet-Engine deshalb nicht ausbaut um nicht noch eine (unnötige) Problemstelle zu produzieren (wie sie ja an anderen Stellen mit "komischen" Entscheidungen sich ohne Not erschaffen haben.
Darauf würde ich mich nicht verlassen. In Zeiten von "Mobile First" kann sowas auch mal ohne Vorankündigung in einem Spring/Autum-Update kommen.